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" f...@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/958104#958104
which I am going to update with my findings based on your help so that
other people might benefit.
Regards,
MajorLabel
