Nginx-Certbot-Debians 3. Maintaining Certbot
The issue
The previous two articles covered installing Nginx in Debain, configured in a way Debian intends. Then enabling Certbot (so security certificates) within that configuration.
However, there is an ongoing issue. Certbot certificates only last for 90 days. That was the case at the time of writing. Certbot have suggested they may reduce the period further, to maintain good security across their generalised system. Roughly speaking, 90 days is about three months. It’s not a long time. Any web service of serious intent will wish to run for longer.
Should I buy a host‐provided security certificate?
Many hosts will offer a service to install and maintain security certificates. This is the easiest way to get a full certificate. These certificates may have extended trust privileges, beyond a Let’s Encrypt certificate. You’ll likely need an extended trust certificate for compliance with online payment systems. In visiting browsers these certificates will show a Green Address Bar.
But there is another side to this. Provision of certificates by hosts is a service which may cost £50 per year or similar. That compares badly to the purchase of a small system slice, which may only cost £10–£20 per year. And an extended certificate is overkill for a website that only wishes to play friendly with modern web formats i.e. wants encrypted page browsing.
How a Let’s Encrypt certificate is updated
The Certbot code sends a message to the Cerbot system, which does any necessary updates. The mechanism is not that important—if you’ve made it through the previous articles, you know it’s working.
The issue is making sure those messages are sent. So that after 90 days the certificate will not expire. Then your web service start returning ‘Insecure’ messages to visitors. To stop this, you will need to set up a timed job on the operating system that runs Certbot before the 90 days expire.
Certbot auto‐renewal
Many Certbot operating system packages will set up a timed job to auto‐renew via Certbot. On Linux, timed jobs are run by ‘cron’ or the newer ‘systemd’ systems. For reassurance, look at cron,
crontab -l
or systemd,
systemctl list-timers
If you see a Systemd timer, you can ask it’s status, check it’s running (the service name will depend on the install method, so operating system configuration),
systemctl status snap.certbot.renew.service
Can also look in here, though packages may not use it,
cat /etc/letsencrypt/renewal-hooks
If no jobs are there, you need to set one up. I think this is rare, packaging works well, so I’m not going to detail (the link above will tell you how to setup a Systemd timer). However, there is one situation I’d like to cover—sometimes the timer fails (perhaps due to maintenance by the host). In which case, a manual renewal will fix that…
Certbot manual checks
I find sometimes the auto‐updating fails. Truth: for one unreliable server I owned I ran an app to ping the server to check it was working. Anyway, if the auto‐update fails so the service starts returning certificate errors, there is no need to do anything drastic. Avoid drastic. Mostly, I find a manual ‘renew’ will fix. Annoying, but easy.
Test expiry of certificates,
certbot --dry-run renew
Renew certificates,
certbot renew
List certificates,
certbot certificates
Look for information in the log,
cat /var/log/letsencrypt/letsencrypt.log