Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
Running dovecot 2.2, apologies if this question has been asked before: I've done the research but couldn't find anything.
I run a server that uses dovecot as a MUA for Postfix and have a Let's Encrypt certificate that auto-renews through certbot on Ubuntu server 16.04. Dovecot did not pick up on the new certificate for the hostname. It did after a restart. To be clear: Let's Encrypt overwrites the previous certificate using the same path and filename. Am I right to assume that Dovecot needs a reload/restart after the certificate has been renewed in order to 'pick up' on the new certificate and if so, would I require a reload or a restart?
Thank you in advance
-- MajorLabel
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.
On 3/14/19 9:14 AM, Guido Goluke, MajorLabel via dovecot wrote:
Running dovecot 2.2, apologies if this question has been asked before: I've done the research but couldn't find anything.
I run a server that uses dovecot as a MUA for Postfix and have a Let's Encrypt certificate that auto-renews through certbot on Ubuntu server 16.04. Dovecot did not pick up on the new certificate for the hostname. It did after a restart. To be clear: Let's Encrypt overwrites the previous certificate using the same path and filename. Am I right to assume that Dovecot needs a reload/restart after the certificate has been renewed in order to 'pick up' on the new certificate and if so, would I require a reload or a restart?
Thank you in advance
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.
Hi,
On 14.03.19 09:33, 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.
on our debian systems, apache reloads the certificate file with
service apache2 reload
I never had to use "restart" to get the new certificate online. The advantage of reload is obvious: in case of a config error the daemon stays running (with the old config) whereas with restart you get a service downtime until you fixed the error.
I guess dovecot's reload mechanism (doveadm reload) also rereads the certificate file, but I did not test that yet. However I just realized that doveadm reload exists with exitcode 0 even if there is an config error. You can only see the error message in the logs. At least the service keeps running (with the old config).
I cannot say anything about postfix as we use exim. At least the way we have configured exim, it neither needs reload or restart but reads the certificate file every time it has to use it.
Best,
Patrick Cernko pcernko@mpi-klsb.mpg.de +49 681 9325 5815 Joint Administration: Information Services and Technology Max-Planck-Institute fuer Informatik & Softwaresysteme
On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote:
[...] the way we have configured exim, it neither needs reload or restart but reads the certificate file every time it has to use it.
What happens if you goof off in the middle of an opeartion, temporarily putting a wrong file instead of the new certificate, and exim starts delivering the new broken certificate right away ? or breaks ? or clients can't connect anymore with TLS ? or don't connect at all if you don't allow non-TLS connexions ?
Yassine.
On Thu, Mar 14, 2019, at 12:09 PM, Yassine Chaouche via dovecot wrote:
On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote:
[...] the way we have configured exim, it neither needs reload or restart but reads the certificate file every time it has to use it.
What happens if you goof off in the middle of an opeartion, temporarily putting a wrong file instead of the new certificate, and exim starts delivering the new broken certificate right away ? or breaks ? or clients can't connect anymore with TLS ? or don't connect at all if you don't allow non-TLS connexions ?
Yassine.
Getting caught in the middle of a cert file or key file update should not happen -- a process that already opened a file will continue to be reading from that file, even if it gets renamed.
But what if exim (or some other process) happens to read the "old" certificate file - and then the "new" private key file (or vice versa)?
A race condition like this seems unlikely but technically possible.
-- K
Hi Yassine, hi Kostya,
On 14.03.19 10:17, Kostya Vasilyev via dovecot wrote:
On Thu, Mar 14, 2019, at 12:09 PM, Yassine Chaouche via dovecot wrote:
On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote:
[...] the way we have configured exim, it neither needs reload or restart but reads the certificate file every time it has to use it.
What happens if you goof off in the middle of an opeartion, temporarily putting a wrong file instead of the new certificate, and exim starts delivering the new broken certificate right away ? or breaks ? or clients can't connect anymore with TLS ? or don't connect at all if you don't allow non-TLS connexions ?
First: It happens the same if I replace the file with a wrong cert AND reload another service deamon and then get interupted. Second: I use ansible to push configurations and usually first push changes to a test system or only one machine. Third: Server administration always has the risk of human error
;-)
Getting caught in the middle of a cert file or key file update should not happen -- a process that already opened a file will continue to be reading from that file, even if it gets renamed.
But what if exim (or some other process) happens to read the "old" certificate file - and then the "new" private key file (or vice versa)?
A race condition like this seems unlikely but technically possible.
We store cert and key together in one PEM file, thus we will always exchange both cert and key in one "atomic" operation.
Best,
Patrick Cernko pcernko@mpi-klsb.mpg.de +49 681 9325 5815 Joint Administration: Information Services and Technology Max-Planck-Institute fuer Informatik & Softwaresysteme
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
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
participants (4)
-
Guido Goluke, MajorLabel
-
Kostya Vasilyev
-
Patrick Cernko
-
Yassine Chaouche