dovecot - Mar 2019 - Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart

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 at mpi-klsb.mpg.de> +49 681 9325 5815
Joint Administration: Information Services and Technology
Max-Planck-Institute fuer Informatik & Softwaresysteme

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5324 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20190314/6a5d50b2/attachment.p7s>

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 at bar.com
-------------

-- K

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 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 at 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