On Thu, Mar 14, 2019, at 11:33 AM, Yassine Chaouche via dovecot wrote:
On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote:
The general answere here is try and see, as you could totally test it on your own. The certificate is read at startup and put in memory for the rest of the execution time. Dovecot won't monitor the file for changes on disk, as this would waste CPU cycles and make dovecot only slower for no reason. The process (or person) that changes the file is responsible to restart dovecot to reload the new certificate in memory.
Yassine. I should mention that this is also true for Apache and postfix.
Yassine. Certbot has a feature to run scripts when renewing / deploying certificates.
https://certbot.eff.org/docs/using.html#renewing-certificates
Certbot also looks for these scripts under
/etc/letsencrypt/renewal-hooks/pre post deploy
FWIW here is my script restart.sh located in /etc/letsencrypt/renewal-hooks/deploy
#!/bin/sh
systemctl restart nginx postfix dovecot
echo "Certbot renewal\n\n$RENEWED_LINEAGE\n\n$RENEWED_DOMAINS" | mail -s "Certbot renewal" foo@bar.com
-- K
Hi, trying to learn the mailing list conventions as Yassine pointed out to me it is customary to reply to the list.
I am guessing the certbot version I use reloads apache config on renewal since I've never had this problem on port 80. Thanks for the renewal-hooks, I had found out that's where they live but wasn't sure if the $RENEWED_DOMAINS were available but from you answer I guess they are.
As Patrick pointed out to me a reload is better since a config error won't stop the services. Thank you all for your kind answers. I've had a topic running on https://serverfault.com/questions/958093/dovecot-issued-expired-certificate/... which I am going to update with my findings based on your help so that other people might benefit.
Regards,
MajorLabel