Re: Dovecot and Letsencrypt certs

[Robert Wolf]

On Wed, 13 Sep 2017, Luigi Rosa wrote:

> Robert Wolf wrote on 13/09/2017 10:26:
> 
> > are you sure? What is the refresh time? Instantly or with some delay? Have
> > you
> > tested what happens if I install new key, but I delay installing correct
> > certificate? Does postfix keep the old key+cert or stop using any cert
> > because
> > the new key is not correct for the current(old) certificate?
> > 
> > On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8
> > I
> > have to reload postfix. Postfix can use the same key+cert even if I deleted
> > these files.
> 
> Two days ago Viktor Dukhovni wrote on Postfix ML:
> 
> /*
> If you run certbot often enough to renew well in advance of expiration,
> reloads of Postfix are unnecessary, and just needlessly interrupt orderly
> processing of email by the queue manager.  Usually the new certificate will
> be automatically in use within "$max_idle * $max_use" seconds, and typically
> sooner, because processes either idle out quickly or reach the re-use limit
> quickly, handling $max_use connections that are exactly $max_idle apart is
> rather unlikely  By default that's 1 seconds or just under 3 hours.
> */


Hi Luigi,

you are right! The smtpd process really start using new certificate+key after 
this timeout (tested with max_use=1). OK, I thought it works similar as rsync 
daemon: the config file is read on new connection, because it starts new 
process. Similarly, the postfix master process starts the smtpd processes and 
they read config and cert+key again. It's clear now.

Still, I prefer to do reload if required and not wait until some timeout 
expires. And e.g. getssl client can check, if the certificate was correctly 
installed. And for this check it needs to run "reload".

And I prefer reload cert+key manually instead of automatically to be sure, WHEN 
it will be done.

So I am ok with dovecot to load cert+key on start and reload:-)


Regards,

Robert.

Re: Dovecot and Letsencrypt certs

[Luigi Rosa]

Robert Wolf wrote on 13/09/2017 10:26:


are you sure? What is the refresh time? Instantly or with some delay? Have you
tested what happens if I install new key, but I delay installing correct
certificate? Does postfix keep the old key+cert or stop using any cert because
the new key is not correct for the current(old) certificate?

On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8 I
have to reload postfix. Postfix can use the same key+cert even if I deleted
these files.


Two days ago Viktor Dukhovni wrote on Postfix ML:

/*
If you run certbot often enough to renew well in advance of expiration,
reloads of Postfix are unnecessary, and just needlessly interrupt orderly
processing of email by the queue manager.  Usually the new certificate will
be automatically in use within "$max_idle * $max_use" seconds, and typically
sooner, because processes either idle out quickly or reach the re-use limit
quickly, handling $max_use connections that are exactly $max_idle apart is
rather unlikely  By default that's 1 seconds or just under 3 hours.
*/




--


Ciao,
luigi

/
+--[Luigi Rosa]--
\

Statistics: The only science that enables different experts using the same
figures to draw different conclusions.
--Evan Esar

Re: Dovecot and Letsencrypt certs

[Robert Wolf]

On Tue, 12 Sep 2017, Daniel Miller wrote:

> And remove that "postfix reload" command - Postfix doesn't require explicit
> reloading. It'll pickup the changed cert automagically.
> 
> Daniel


Hoi Daniel,

are you sure? What is the refresh time? Instantly or with some delay? Have you 
tested what happens if I install new key, but I delay installing correct 
certificate? Does postfix keep the old key+cert or stop using any cert because 
the new key is not correct for the current(old) certificate?

On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8 I 
have to reload postfix. Postfix can use the same key+cert even if I deleted 
these files.


Reagrds,

Robert.

Re: Dovecot and Letsencrypt certs

[Adi Pircalabu]

On 13/09/2017 05:31, Joseph Tam wrote:

On Tue, 12 Sep 2017, dovecot-request wrote:


What's wrong with using a certbot "post-hook" script such as:

#!/bin/bash
echo "Letsencrypt renewal hook running..."
echo "RENEWED_DOMAINS=$RENEWED_DOMAINS"
echo "RENEWED_LINEAGE=$RENEWED_LINEAGE"

if grep --quiet "your.email.domain" <<< "$RENEWED_DOMAINS"; then
??? /usr/local/sbin/dovecot reload
?? /usr/sbin/postfix reload
fi


Nothing, if you let your certbot run as root.  (I'm assuming that's
how these hooks work -- it's called after cert renewal using the same
credentials as the certbot.)

If you use privilege separation, and run the certbot as a regular user
process, this won't work.  You might have this scenario if, for example
using the context of web serving, you serve many virtual sites with
different owners, and you don't want give each owner administrative
access.


There are options when running certbot as non-privileged user, such as 
sudo, inotifywait -s -e modify /path/to/bundle.pem && doveadm reload and 
so on.


--
Adi Pircalabu

Re: Dovecot and Letsencrypt certs

[Joseph Tam]

On Tue, 12 Sep 2017, dovecot-requ...@dovecot.org wrote:


What's wrong with using a certbot "post-hook" script such as:

#!/bin/bash
echo "Letsencrypt renewal hook running..."
echo "RENEWED_DOMAINS=$RENEWED_DOMAINS"
echo "RENEWED_LINEAGE=$RENEWED_LINEAGE"

if grep --quiet "your.email.domain" <<< "$RENEWED_DOMAINS"; then
??? /usr/local/sbin/dovecot reload
?? /usr/sbin/postfix reload
fi


Nothing, if you let your certbot run as root.  (I'm assuming that's
how these hooks work -- it's called after cert renewal using the same
credentials as the certbot.)

If you use privilege separation, and run the certbot as a regular user
process, this won't work.  You might have this scenario if, for example
using the context of web serving, you serve many virtual sites with
different owners, and you don't want give each owner administrative
access.

Joseph Tam 

Re: Dovecot and Letsencrypt certs

[Daniel Miller]

And remove that "postfix reload" command - Postfix doesn't require 
explicit reloading. It'll pickup the changed cert automagically.


Daniel

On 9/12/2017 9:26 AM, Daniel Miller wrote:

What's wrong with using a certbot "post-hook" script such as:

#!/bin/bash
echo "Letsencrypt renewal hook running..."
echo "RENEWED_DOMAINS=$RENEWED_DOMAINS"
echo "RENEWED_LINEAGE=$RENEWED_LINEAGE"

if grep --quiet "your.email.domain" <<< "$RENEWED_DOMAINS"; then
    /usr/local/sbin/dovecot reload
   /usr/sbin/postfix reload
fi

Daniel

On 9/11/2017 1:57 PM, Joseph Tam wrote:

 writes:


"writing a script to check the certs" - there is no need to write any
scripts. As one mentioned, it's done by a hook to certbot. Please read
the manuals for LE or certbot. The issue you have is quite common and
of course certbot designed to do it for you.


Won't work, of course, if you employ the least-privilege security 
principle

and run the certbot as a non-privileged user.  You'll need a script with
administrator privileges to detect cert renewals and restart the 
service.


I can't willy-nilly restart dovecot to pick up renewed certs without
webmail disruptions.  (My webmail uses persistent IMAP sessions.)
All users get dumped and need to re-authenticate.  If a user happens to
be drafting a message that took 2 hours to compose, I will surely hear
about it.  I should probably install a IMAP proxy to isolate the effects
of restarts.  Most mail readers cope with restarts just fine, though.

Joseph Tam 

Re: Dovecot and Letsencrypt certs

[Daniel Miller]

What's wrong with using a certbot "post-hook" script such as:

#!/bin/bash
echo "Letsencrypt renewal hook running..."
echo "RENEWED_DOMAINS=$RENEWED_DOMAINS"
echo "RENEWED_LINEAGE=$RENEWED_LINEAGE"

if grep --quiet "your.email.domain" <<< "$RENEWED_DOMAINS"; then
    /usr/local/sbin/dovecot reload
   /usr/sbin/postfix reload
fi

Daniel

On 9/11/2017 1:57 PM, Joseph Tam wrote:

 writes:


"writing a script to check the certs" - there is no need to write any
scripts. As one mentioned, it's done by a hook to certbot. Please read
the manuals for LE or certbot. The issue you have is quite common and
of course certbot designed to do it for you.


Won't work, of course, if you employ the least-privilege security 
principle

and run the certbot as a non-privileged user.  You'll need a script with
administrator privileges to detect cert renewals and restart the service.

I can't willy-nilly restart dovecot to pick up renewed certs without
webmail disruptions.  (My webmail uses persistent IMAP sessions.)
All users get dumped and need to re-authenticate.  If a user happens to
be drafting a message that took 2 hours to compose, I will surely hear
about it.  I should probably install a IMAP proxy to isolate the effects
of restarts.  Most mail readers cope with restarts just fine, though.

Joseph Tam 

Re: Dovecot and Letsencrypt certs

[Joseph Tam]

 writes:


"writing a script to check the certs" - there is no need to write any
scripts. As one mentioned, it's done by a hook to certbot. Please read
the manuals for LE or certbot. The issue you have is quite common and
of course certbot designed to do it for you.


Won't work, of course, if you employ the least-privilege security principle
and run the certbot as a non-privileged user.  You'll need a script with
administrator privileges to detect cert renewals and restart the service.

I can't willy-nilly restart dovecot to pick up renewed certs without
webmail disruptions.  (My webmail uses persistent IMAP sessions.)
All users get dumped and need to re-authenticate.  If a user happens to
be drafting a message that took 2 hours to compose, I will surely hear
about it.  I should probably install a IMAP proxy to isolate the effects
of restarts.  Most mail readers cope with restarts just fine, though.

Joseph Tam 

Re: Dovecot and Letsencrypt certs

[Arkadiusz Miśkiewicz]

On Friday 08 of September 2017, Ralph Seichter wrote:
> On 08.09.2017 16:20, LuKreme wrote:

> > However, it seems like checking the certs is something that dovecot
> > should be doing on its own.
> 
> What is Dovecot supposed to do? Keep track of the certificate expiry
> date? 

That was already discussed but due to other reason. dovecot shouldn't load SSL 
certificates into memory and instead open  & load cert on demand (when client 
connects and requests particular domain via SNI (or default if no SNI)).

Why? Because dovecot *cannot* handle thousands of virtual domains and SSL 
certificates for these. It wastes so much RAM and timeouts on reloads in such 
case. Tested here. [1]

That's why the only sensible solution is to work like exim - load cert from 
disk on demand.

That fixes both problems - ram wasting/timeouts and refreshing certificates.


> -Ralph

1. https://dovecot.org/list/dovecot/2016-October/105855.html

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: Dovecot and Letsencrypt certs

[Bill Shirley]

Oh, also I removed the '2>1> /dev/null' from the acme.sh crontab entry so that
it will always send an email; and entered this in sieve:
# --- let's encrypt ---
if header :contains "subject" "acme.sh" {
  if body :regex "Error[[:space:]]+renew" {
#    redirect :copy "b...@example.com";
    addflag "$label1";    # Thunderbird red
    stop;
  }
  if body :regex "-BEGIN CERTIFICATE-" {
#    redirect :copy "b...@example.com";
    addflag "$label4";    # Thunderbird blue
    stop;
  }
  fileinto "AASystemAdministration.Cron.certificate";
  stop;
}
The redirect :copy I enable for my other servers to forward a copy
to me.

HTH,
BIll


On 9/9/2017 3:16 PM, Bill Shirley wrote:

If you're using acme.sh:
acme.sh --installcert -d imap.example.com \
  --keypath /etc/pki/dovecot/private/imap.example.com.pem \
  --certpath /etc/pki/dovecot/certs/imap.example.com.crt \
  --fullchainpath /etc/pki/dovecot/certs/imap.example.com.full.chain.crt \
  --reloadcmd    "systemctl reload dovecot.service"

HTH,
Bill

On 9/8/2017 9:56 AM, Darac Marjal wrote:

On Fri, Sep 08, 2017 at 06:47:25AM -0600, @lbutlr wrote:

So this morning at 4am I was awoken to my mail clients getting certificate 
errors for an expired certificate.

I hopped on to the server and checked and… no, the LE certs renewed last month 
and are valid until November.

After some moments of confusion I noticed that dovecot had been running since before the renewal, so I did a quick service 
dovecot restart which fixed everything.


Should dovecot check for certs being refreshed? Or is this an artifact of my using symbolic links everywhere to point to the 
newest LE certs (which are themselves links the dehydrate script creates to point to the newest cert-1502534746.csr etc files?


As you're using dehydrated, I can share what I do. My hook script basically calls "run-parts /etc/dehydrated/hooks.d/" so I 
can just drop hook scripts into that directory. Then in the hooks.d directory, I have the following:


#!/bin/bash

set -e
set -u
set -o pipefail

if [[ ${1} == "deploy_cert" && ${2} == "mail.darac.org.uk" ]]; then
    echo " + Hook: Restarting Dovecot..."
    /usr/sbin/service dovecot restart
fi

That means that dovecot will be restarted only if the certificate for the mail server is being deployed. If dehydrated runs, 
but fails to renew the certificate, then dovecot won't be restarted. Similarly, if it renews a different certificate, dovecot 
won't be restarted.


Hope that helps.




Should I just create a monthly cron to restart dovecot or is there something 
else?

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Dovecot and Letsencrypt certs

[Bill Shirley]

If you're using acme.sh:
acme.sh --installcert -d imap.example.com \
  --keypath /etc/pki/dovecot/private/imap.example.com.pem \
  --certpath /etc/pki/dovecot/certs/imap.example.com.crt \
  --fullchainpath /etc/pki/dovecot/certs/imap.example.com.full.chain.crt \
  --reloadcmd    "systemctl reload dovecot.service"

HTH,
Bill

On 9/8/2017 9:56 AM, Darac Marjal wrote:

On Fri, Sep 08, 2017 at 06:47:25AM -0600, @lbutlr wrote:

So this morning at 4am I was awoken to my mail clients getting certificate 
errors for an expired certificate.

I hopped on to the server and checked and… no, the LE certs renewed last month 
and are valid until November.

After some moments of confusion I noticed that dovecot had been running since before the renewal, so I did a quick service 
dovecot restart which fixed everything.


Should dovecot check for certs being refreshed? Or is this an artifact of my using symbolic links everywhere to point to the 
newest LE certs (which are themselves links the dehydrate script creates to point to the newest cert-1502534746.csr etc files?


As you're using dehydrated, I can share what I do. My hook script basically calls "run-parts /etc/dehydrated/hooks.d/" so I 
can just drop hook scripts into that directory. Then in the hooks.d directory, I have the following:


#!/bin/bash

set -e
set -u
set -o pipefail

if [[ ${1} == "deploy_cert" && ${2} == "mail.darac.org.uk" ]]; then
    echo " + Hook: Restarting Dovecot..."
    /usr/sbin/service dovecot restart
fi

That means that dovecot will be restarted only if the certificate for the mail server is being deployed. If dehydrated runs, 
but fails to renew the certificate, then dovecot won't be restarted. Similarly, if it renews a different certificate, dovecot 
won't be restarted.


Hope that helps.




Should I just create a monthly cron to restart dovecot or is there something 
else?

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Dovecot and Letsencrypt certs

[Вадим Бажов]

"writing a script to check the certs" - there is no need to write any
scripts. As one mentioned, it's done by a hook to certbot. Please read
the manuals for LE or certbot. The issue you have is quite common and
of course certbot designed to do it for you.
The manual: https://certbot.eff.org/docs/using.html#renewing-certificates.
Thats it. Problem solved.

2017-09-09 0:18 GMT+05:00 @lbutlr :
> On 08 Sep 2017, at 12:21, Ralph Seichter  wrote:
>> On 08.09.2017 19:51, @lbutlr wrote:
>>> How I would do it is IF the certificate is expired, the dovecot should
>>> check if there is a new cert and if so, load it.
>
>> New cert as in file modification date or checksum changed?
>
> Either one, but checksum is going to be more reliable.
>
>> Might work. Still, from what I seem to remember, Dovecot loads certificate 
>> data before dropping privileges, which is why reloading the data might be 
>> problematic without some changes.
>
> Can't dovecot reload itself? That could be a problem if not.
>
>> Not worth spending development effort on, IMO, given that Dovecot can easily 
>> be restarted by the external processes that update the cert (like Certbot 
>> hook, Ansible, etc.).
>
> All I'm saying is that it's a failure event that doesn't need to occur.
>
> --
> Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Dovecot and Letsencrypt certs

[@lbutlr]

On 08 Sep 2017, at 12:21, Ralph Seichter  wrote:
> On 08.09.2017 19:51, @lbutlr wrote:
>> How I would do it is IF the certificate is expired, the dovecot should
>> check if there is a new cert and if so, load it.

> New cert as in file modification date or checksum changed?

Either one, but checksum is going to be more reliable.

> Might work. Still, from what I seem to remember, Dovecot loads certificate 
> data before dropping privileges, which is why reloading the data might be 
> problematic without some changes.

Can't dovecot reload itself? That could be a problem if not.

> Not worth spending development effort on, IMO, given that Dovecot can easily 
> be restarted by the external processes that update the cert (like Certbot 
> hook, Ansible, etc.).

All I'm saying is that it's a failure event that doesn't need to occur.

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Dovecot and Letsencrypt certs

[Ralph Seichter]

On 08.09.2017 19:51, @lbutlr wrote:

> How I would do it is IF the certificate is expired, the dovecot should
> check if there is a new cert and if so, load it.

New cert as in file modification date or checksum changed? Might work.
Still, from what I seem to remember, Dovecot loads certificate data
before dropping privileges, which is why reloading the data might be
problematic without some changes. Not worth spending development effort
on, IMO, given that Dovecot can easily be restarted by the external
processes that update the cert (like Certbot hook, Ansible, etc.).

-Ralph

Re: Dovecot and Letsencrypt certs

[@lbutlr]

On 08 Sep 2017, at 09:28, Вадим Бажов  wrote:
> "I think it’s probably easier to just kick dovecot once a month." -
> that's not good from system administration's point of view. You can
> get into trouble when certificate is renewed but dovecot isn't
> reloaded yet.

That's simply not possible. The cert renews well before it expires.

> "it seems like checking the certs is something that dovecot should be
> doing on its own" if dovecot loads it in memory, it shouldn't reread
> certificates.

Of course it should because certs are DESIGNED to expire and MUST expire, and 
dovecot certainly has the ability to see when the cert expires.

> Why to take servers resources just 'because of something
> may be changed'

Something WILL be changed, absolutely certain of that. All certs expire.

> restarting dovecot with no need ?

restarting/reloading dovecot is trivial and takes far less time than writing a 
script to check the certs and then creating a crontab for that which also gives 
a tertiary point of failure.

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Dovecot and Letsencrypt certs

[Ralph Seichter]

On 08.09.2017 16:20, LuKreme wrote:

> That is a great solution, but I think it’s probably easier to just
> kick dovecot once a month.

Certbot hooks are very easy to write, and are only executed when the
certificate is updated. In that light, I can see no advantage in "kick
dovecot once a month". ;-)

> However, it seems like checking the certs is something that dovecot
> should be doing on its own.

What is Dovecot supposed to do? Keep track of the certificate expiry
date? And if that is passed, then what? Automatically shutdown/restart?
What if the certificate has not been updated in between? I think that
handling certificates is better left to the administrator.

-Ralph

Re: Dovecot and Letsencrypt certs

[Вадим Бажов]

"I think it’s probably easier to just kick dovecot once a month." -
that's not good from system administration's point of view. You can
get into trouble when certificate is renewed but dovecot isn't
reloaded yet. And, doing something via cron just by-guess, once a
month - is a no no logic.
"it seems like checking the certs is something that dovecot should be
doing on its own" if dovecot loads it in memory, it shouldn't reread
certificates. Why to take servers resources just 'because of something
may be changed' restarting dovecot with no need ?
And, never do restart if reload suits your needs. But check it first,
if reload action rereads certificate from file system.

2017-09-08 19:20 GMT+05:00 LuKreme :
> On Sep 8, 2017, at 07:56, Darac Marjal  wrote:
>>  #!/bin/bash
>>
>>set -e
>>set -u
>>set -o pipefail
>>
>>if [[ ${1} == "deploy_cert" && ${2} == "mail.darac.org.uk" ]]; then
>>echo " + Hook: Restarting Dovecot..."
>>/usr/sbin/service dovecot restart
>>fi
>>
>> That means that dovecot will be restarted only if the certificate for the 
>> mail server is being deployed. If dehydrated runs, but fails to renew the 
>> certificate, then dovecot won't be restarted. Similarly, if it renews a 
>> different certificate, dovecot won't be restarted.
>
> That is a great solution, but I think it’s probably easier to just kick 
> dovecot once a month.
>
> 4 4 4 * * service dovecot restart
>
> However, it seems like checking the certs is something that dovecot should be 
> doing on its own.
>
> --
> This is my signature. There are many like it, but this one is mine.

Re: Dovecot and Letsencrypt certs

[LuKreme]

On Sep 8, 2017, at 07:56, Darac Marjal  wrote:
>  #!/bin/bash
> 
>set -e
>set -u
>set -o pipefail
>
>if [[ ${1} == "deploy_cert" && ${2} == "mail.darac.org.uk" ]]; then
>echo " + Hook: Restarting Dovecot..."
>/usr/sbin/service dovecot restart
>fi
> 
> That means that dovecot will be restarted only if the certificate for the 
> mail server is being deployed. If dehydrated runs, but fails to renew the 
> certificate, then dovecot won't be restarted. Similarly, if it renews a 
> different certificate, dovecot won't be restarted.

That is a great solution, but I think it’s probably easier to just kick dovecot 
once a month.

4 4 4 * * service dovecot restart

However, it seems like checking the certs is something that dovecot should be 
doing on its own.

-- 
This is my signature. There are many like it, but this one is mine.

Re: Dovecot and Letsencrypt certs

[Darac Marjal]

On Fri, Sep 08, 2017 at 06:47:25AM -0600, @lbutlr wrote:

So this morning at 4am I was awoken to my mail clients getting certificate 
errors for an expired certificate.

I hopped on to the server and checked and… no, the LE certs renewed last month 
and are valid until November.

After some moments of confusion I noticed that dovecot had been running since 
before the renewal, so I did a quick service dovecot restart which fixed 
everything.

Should dovecot check for certs being refreshed? Or is this an artifact of my 
using symbolic links everywhere to point to the newest LE certs (which are 
themselves links the dehydrate script creates to point to the newest 
cert-1502534746.csr etc files?


As you're using dehydrated, I can share what I do. My hook script 
basically calls "run-parts /etc/dehydrated/hooks.d/" so I can just drop 
hook scripts into that directory. Then in the hooks.d directory, I have 
the following:


#!/bin/bash

set -e
set -u
set -o pipefail

if [[ ${1} == "deploy_cert" && ${2} == "mail.darac.org.uk" ]]; then
echo " + Hook: Restarting Dovecot..."
/usr/sbin/service dovecot restart
fi

That means that dovecot will be restarted only if the certificate for the 
mail server is being deployed. If dehydrated runs, but fails to renew 
the certificate, then dovecot won't be restarted. Similarly, if it 
renews a different certificate, dovecot won't be restarted.


Hope that helps.




Should I just create a monthly cron to restart dovecot or is there something 
else?

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.


--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Dovecot and Letsencrypt certs

[Eduardo M KALINOWSKI]

On 08-09-2017 09:47, @lbutlr wrote:
> Should dovecot check for certs being refreshed? Or is this an artifact of my 
> using symbolic links everywhere to point to the newest LE certs (which are 
> themselves links the dehydrate script creates to point to the newest 
> cert-1502534746.csr etc files?
>
> Should I just create a monthly cron to restart dovecot or is there something 
> else?
Dovecot needs a restart after the certificate is changed. certbot allows
you to define hooks to be run after a certificate is renewed, so you
could use that feature to restart dovecot after the renewal. Other
clients might have similar features.

-- 
While you recently had your problems on the run, they've regrouped and
are making another attack.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Dovecot and Letsencrypt certs

[Вадим Бажов]

Dovecot seems to load certificates into memory and don't refresh them
until restart, or may be reload. And this is a correct logic. You
better add restart/reload task to the LE cron job after the successful
renewal of LE certificate.
Check that it really works as it should.
Dovecot shouldn't be restarted/reloaded if certificate wasn't changed.

2017-09-08 17:47 GMT+05:00 @lbutlr :
> So this morning at 4am I was awoken to my mail clients getting certificate 
> errors for an expired certificate.
>
> I hopped on to the server and checked and… no, the LE certs renewed last 
> month and are valid until November.
>
> After some moments of confusion I noticed that dovecot had been running since 
> before the renewal, so I did a quick service dovecot restart which fixed 
> everything.
>
> Should dovecot check for certs being refreshed? Or is this an artifact of my 
> using symbolic links everywhere to point to the newest LE certs (which are 
> themselves links the dehydrate script creates to point to the newest 
> cert-1502534746.csr etc files?
>
> Should I just create a monthly cron to restart dovecot or is there something 
> else?
>
> --
> Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Dovecot and Letsencrypt certs

[@lbutlr]

So this morning at 4am I was awoken to my mail clients getting certificate 
errors for an expired certificate.

I hopped on to the server and checked and… no, the LE certs renewed last month 
and are valid until November.

After some moments of confusion I noticed that dovecot had been running since 
before the renewal, so I did a quick service dovecot restart which fixed 
everything.

Should dovecot check for certs being refreshed? Or is this an artifact of my 
using symbolic links everywhere to point to the newest LE certs (which are 
themselves links the dehydrate script creates to point to the newest 
cert-1502534746.csr etc files?

Should I just create a monthly cron to restart dovecot or is there something 
else?

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.