Many documentations outsides, but some of them are out of date, and some of them only applies to already setup servers like Apaches, Nginx, etc. So I have summed up my experience on this.
sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:certbot/certbot -y
sudo apt-get update -y
sudo apt-get install certbot -y
There are mainly 2 ways a CA can verify a domain integrity.
- Through Domain Name TXT record challenge
- Through HTTP Server challenge
Both of them will have an ACME challenge that a CA will verify against it.
You will have to do this process every 90 days if your certs are from Let's Encrypt or SSL For Free.
sudo certbot certonly --standalone --preferred-challenges http -d domain.com -d www.domain.com
standalone means certbot will spin up a temporary web server listening port 80 for HTTP-01 challenge by its python script. So you don't need a webserver running.
You shall obtain certificates at /etc/letsencrypt/live/domain.com/
Make symlinks for easy access
sudo ln -s /etc/letsencrypt/live/domain.com/ /yourprojectfolder/ssl/
sudo chmod 755 -R /etc/letsencrypt/{live,archive}
Archive is included here because certificates in live folder are just symlinks back to archive.
Often times you want to do preparations before and after setup of SSL certificates, setup hooks will help you do so
sudo sh -c 'printf "#!/bin/sh\nservice haproxy stop\n" > /etc/letsencrypt/renewal-hooks/pre/haproxy.sh'
sudo sh -c 'printf "#!/bin/sh\nservice haproxy start\n" > /etc/letsencrypt/renewal-hooks/post/haproxy.sh'
sudo chmod 755 /etc/letsencrypt/renewal-hooks/pre/haproxy.sh
sudo chmod 755 /etc/letsencrypt/renewal-hooks/post/haproxy.sh
One suggestion is to allow access by non-root users
chmod 755 -R /etc/letsencrypt/{live,archive}
Checks
sudo cat /etc/cron.d/certbot
should contain
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc. Renewal will only occur if expiration
# is within 30 days.
#
# Important Note! This cronjob will NOT be executed if you are
# running systemd as your init system. If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob. For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
This job will be executed by the period specified by the cron expression in the file.
As long as the file exist in the cron.d directory, the job will be executed.
$ grep CRON /var/log/syslog
sudo certbot renew --dry-run
tar -czvf backup.tar.gz /etc/letsencrypt
sudo certbot revoke --cert-path /path/to/cert/server.cert --key-path /path/to/cert/server.key
sudo certbot delete
Logs are located at
/var/log/letsencrypt/letsencrypt.log
might be quite long, so use tail or vi if possible.
Registering wildcard domain (e.g. *.domain.com) requires DNS-01 challenge, which requires to change NameServer's record, and cannot be renewed easily. It will require you to update the DNS records if API is available by your NameServer.
sudo certbot -d $DOMAIN -d $WILDCARD --manual --preferred-challenges dns certonly
Manual procedure also doesn't have very much flexibility, only specific kinds of plugins are allowed with manual setup for renewal (Maybe I'm wrong)
https://certbot.eff.org/docs/using.html#certbot-command-line-options
https://docs.bitnami.com/aws/how-to/understand-bncert/
https://www.liquidweb.com/kb/how-to-display-list-all-jobs-in-cron-crontab/
https://letsencrypt.org/docs/challenge-types/
Other than cron.d, crontab can be setup to perform similar periodic tasks
List crontab
crontab -l
Backup crontab
crontab -l > cron-backup.txt
Remove crontab
crontab -r
Restore crontab
crontab cron-backup.txt