Thank you very much for your detailed answer. I did a little more research, and as it turns out, the timers are not really useful to me since I’m using
certbot with the
standalone plugin. Here’s how I issued my initial certificate:
# certbot certonly --non-interactive --email firstname.lastname@example.org \
--preferred-challenges http --standalone --agree-tos --renew-by-default \
--webroot-path /var/www/html -d sd-155842.dedibox.fr
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for sd-155842.dedibox.fr
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/sd-155842.dedibox.fr/fullchain.pem
Key is saved at: /etc/letsencrypt/live/sd-155842.dedibox.fr/privkey.pem
This certificate expires on 2023-08-03.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
This is the most simple and bone-headed method, and the reason I’m using it is that back in 2015 when the first public beta of Let’s Encrypt certificates were available, I was running Slackware Linux on my servers and the
standalone plugin was the only one available. So in all honesty, it’s force of habit, I’d say.
On a side note, I’ve written a
letsencrypt.sh shell script that greatly simplifies the creation and renewal of all my certificates, since it can happen that I have a few dozen certificates for various domains and subdomains on a single machine:
The only drawback of getting certificates with the
standalone plugin is the fact that it requires TCP port 80 to be available. So if I run
certbot renew with the web server running, I get the following error message:
Failed to renew certificate sd-155842.dedibox.fr with error: Could not bind TCP port 80
because it is already in use by another process on this system (such as a web server).
Please stop the program in question and then try again.
The pragmatic solution I have found for this is that I run the
letsencrypt.sh script manually every couple months or so only. It stops Apache, renews all the certificates and starts Apache again. Service interruption is no more than 30 seconds, and I only host non-critical stuff like SME websites, blogs, etc. I do this on a Sunday morning when the whole country’s asleep.
I wonder if it would be worth the hassle to learn using the
webroot plugin (which apparently can renew certificates with Apache running). Unfortunately the Certbot documentation is not exactly a model of clarity in this regard.