Recently I had an issue where certbot failed to renew my certificate due to a misconfiguration in my Apache config file. I managed to fix the issue and get the certificate renewed, and everything worked fine as far as my webserver is concerned. However I also use the same certificate in both Dovecot and Postfix and my mail clients all started complaining about an expired certificate.
Eventually I realized that restarting those services fixed the problem. I’m not sure about whether this is related to Dovecot or Postfix because I restarted both at once and the issue disappeared. But somehow it seems that one (or both) of those services possibly caches the certificate.
Does anyone know for sure which of these would have been the culprit? I was thinking maybe I need to restart those services when a renewal takes place but can that be done as part of the certbot renewal process? Or is there possibly a way to turn off certificate caching? Any help here is appreciated.
No, nothing changed with the path. As I said everything is fine now after restarting both services. Since a restart was all that was necessary we can rule out any issue with my config files.
Interesting. Thanks - is this only required by Postfix? Does Dovecot require restart as well? Where do I make that change? Would this be a change to the cron.d script?
Almost all services will keep the certificate in memory, it’s a lot more efficient than reading it from disk constantly. You will need to reload that somehow. Some services, like Apache and Nginx, have a ‘reload’ function that leaves the service available during a reload. Others require a full restart. Certbot, depending on how you used it initially, will usually reload Apache for you.
Can you give me the exact syntax to make sure these services get restarted on subsequent renewals? Also, is this something that might get overwritten on future updates?
It would be really great if we had a certbot user configuration file where post renewal hooks or other settings could be stored without worry of them being touched. Is there such a thing?
Postfix and Dovecot both support the reloading as reported earlier. I would suggest to search Google if this is also possible for your current method using the service application (I don't have experience with it).
There are several: the global one is /etc/letsencrypt/cli.ini and there's one per existing certificate in /etc/letsencrypt/renewal/ (though those are overwritten when you renew with specific options). You can also place renewal hook scripts in the directories under /etc/letsencrypt/renewal-hooks/.
If systemd is present, service seems to act as a backward-compatible wrapper around systemctl. So it should be possible.
However, if systemd is present, the cron entry installed by the certbot package is ignored in favour of the systemd timer, so modifying it won't do any good.
It would be better to update the renewal configuration file(s), as that works no matter which scheduling method is used.
The recommended way to do that is to run certbot again with the correct options so that they get saved automatically to the per-certificate renewal config files. For example:
The --force-renewal option is needed to force it to renew immediately so that it will save the new configuration (normally it skips certificates that aren't close to expiry), and --deploy-hook is slightly better than --post-hook here because it only runs after a successful renewal. If you have multiple certificates you should add the --cert-name option to tell certbot which one you want to update.
(related: any chance an explanatory comment regarding systemd could be added to that cron job? It seems to confuse a lot of people… and what’s the best place to make such a suggestion? Guessing @hlieberman is the person to ask, sorry if I got that wrong)
I'm not sure about this. Ubuntu 18 definitely uses systemd, but I have all sorts of things running in my crontab and cron is definitely checking cron.d and executing those entries.
The certbot cronjob specifically checks if you're running systemd, and it refuses to run if so. That's because we install BOTH a cronjob (for people not using systemd) and a systemd timer (for people who are). We don't want them both to run, though, so the cronjob short-circuits itself if you're running systemd.
That's what the \! -d /run/systemd/system part of the test is checking for inside the cronjob.
Ahh… I see. Thanks for explaining. I took a look at the renewal hooks directory and will have to do a bit more reading on this one. I’ll also look at the per-certificate config. Really appreciate the support you’ve provided here.