· 1 minute read

Notes on Let’s Encrypt

I’ve been using SSL certificates from Let’s Encrypt for a while now and though there’s no direct integration between certbot and nginx, it was all relatively straightforward to configure.

I’ve created a small nginx config file that can be included in any server block where I’m using LE certificates. This means authentication can use webroot challenges.

location ~ /.well-known {
root /path/to/challenges;
allow all;
}

To request a new certificate for a new domain (using letsencrypt-auto, but that can be swapped out for certbot-auto depending on the client version) run the following as root, replacing the text in brackets:
/opt/letsencrypt/letsencrypt-auto certonly --agree-tos --email <email> --webroot -w </path/to/challenges> -d <domain>

If the certificate should cover multiple subdomains, that’s possible by specifying -d <domain> multiple times. The caveat is that, if you later stop making the .well-known directory available on just one of the subdomains on the certificate, your renewal will fail (as I found out).

To set up auto-renewal, add the following to the root crontab:
30 2 * * 7 /opt/letsencrypt/letsencrypt-auto renew -q --post-hook "service nginx reload" >> /var/log/le-renew.log
This causes the renewal job to run at 2:30am every Sunday, restart the server when it completes and log any errors to /var/log/le-renew.log.

To avoid the problem of the renewal failing when you decommission a subdomain, it’s very straightforward to request a new certificate for the available domains. Because Lets’ Encrypt will only automatically renew certificates when they are nearing expiry to keep you from hitting the rate limits, you will likely need to force the renewal using the following command and restart the web server:
/opt/letsencrypt/letsencrypt-auto renew --force-renewal --allow-subset-of-names

Tags: ,