Hi,
I get my Email from my own SMTP server on the internet using "fetchmail". Some time ago I did the smart thing and configured dovecot to use SSL and the letsencrypt certificate that automatically renews.
Welllll..... a few days ago my certificate expired and the fetchmail deamon running in the background had nowhere to complain. So I didn't notice.
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th.
So.... Feature request: check the expiry date on the SSL certificate as it is being loaded and check for a new certificate if it HAS expired.
If you worry about performance, this could be done where:
TLS handshaking: SSL_accept() failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45
is reported. That would mean that ONE client will once get the error before dovecot fixes it. My personal fix is to restart dovecot once a week from now on.
I might be running an older version:
# 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.21 (92477967) # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 LTS
if it has already been fixed, please accept my apologies.
Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
On 09/10/2020 11:16 Rogier Wolff r.e.wolff@bitwizard.nl wrote:
Hi,
I get my Email from my own SMTP server on the internet using "fetchmail". Some time ago I did the smart thing and configured dovecot to use SSL and the letsencrypt certificate that automatically renews.
Welllll..... a few days ago my certificate expired and the fetchmail deamon running in the background had nowhere to complain. So I didn't notice.
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th.
So.... Feature request: check the expiry date on the SSL certificate as it is being loaded and check for a new certificate if it HAS expired.
If you worry about performance, this could be done where:
TLS handshaking: SSL_accept() failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45
is reported. That would mean that ONE client will once get the error before dovecot fixes it. My personal fix is to restart dovecot once a week from now on.
I might be running an older version:
# 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.21 (92477967) # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 LTS
if it has already been fixed, please accept my apologies.
Roger.
That is indeed old version, but no, there is no automatic certificate reloading in Dovecot yet. This has been suggested before, and we have it in our internal issue tracker, but unfortunately I can't promise any date when it will be done.
Aki
Does a dovecot reload not do that? For a webserver I just set a flag and a cron job. Whenever I put a new cert, the webserver reloads.
-----Original Message----- To: Rogier Wolff; dovecot@dovecot.org Subject: Re: Feature request.
On 09/10/2020 11:16 Rogier Wolff r.e.wolff@bitwizard.nl wrote:
Hi,
I get my Email from my own SMTP server on the internet using "fetchmail". Some time ago I did the smart thing and configured dovecot to use SSL and the letsencrypt certificate that automatically renews.
Welllll..... a few days ago my certificate expired and the fetchmail deamon running in the background had nowhere to complain. So I didn't notice.
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th.
So.... Feature request: check the expiry date on the SSL certificate as it is being loaded and check for a new certificate if it HAS expired.
If you worry about performance, this could be done where:
TLS handshaking: SSL_accept() failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45
is reported. That would mean that ONE client will once get the error before dovecot fixes it. My personal fix is to restart dovecot once a week from now on.
I might be running an older version:
# 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version
0.4.21 (92477967) # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 LTS
if it has already been fixed, please accept my apologies.
Roger.
That is indeed old version, but no, there is no automatic certificate reloading in Dovecot yet. This has been suggested before, and we have it in our internal issue tracker, but unfortunately I can't promise any date when it will be done.
Aki
On Fri, Oct 09, 2020 at 11:21:09AM +0300, Aki Tuomi wrote:
On 09/10/2020 11:16 Rogier Wolff r.e.wolff@bitwizard.nl wrote: So.... Feature request: check the expiry date on the SSL certificate as it is being loaded and check for a new certificate if it HAS expired.
That is indeed old version, but no, there is no automatic certificate reloading in Dovecot yet. This has been suggested before, and we have it in our internal issue tracker, but unfortunately I can't promise any date when it will be done.
Ok. I'm glad it is noted somewhere and that hopefully someday someone will get to it. Once a problem is known the solution is often easy. So for example I spent time figuring out why dovecot was rejecting the fetchmail SSL certificate, while in fact it was the other way around.
When my certificate next expires I'll probably NOT find out that my fix works or not. It'll go smoothly and I'll have forgotten about it. So no "date" on it is not a problem for me. I'm happy if my report helps put something on the radar and makes things better over time.
On Friday: Marc Roos wrote:
Does a dovecot reload not do that?
You mean a reload as opposed to a restart? Maybe. So a restart might be more expensive, but my server is way overpowered and can handle the restart.
Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
On 09/10/2020 4:16 pm, Rogier Wolff wrote:
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th.
I guess you could do a few things yourself to make sure the cert is valid. Thinking out loud:
Blunt instrument approach: Just restart/reload Dovecot once a week via a cron job. Letsencrypt will renew certs with less than 15 days to go, so once a week should catch it.
Check certificate validity with openssl command line client via a script. I wrote one that goes around all the websites under my care and checks. Should be possible to do it for mail servers too?
Check manually with a tool like this https://ssl-tools.net/mailservers/
P.
On 09/10/2020 11:50, Plutocrat wrote:
On 09/10/2020 4:16 pm, Rogier Wolff wrote:
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th. I guess you could do a few things yourself to make sure the cert is valid. Thinking out loud:
- Blunt instrument approach: Just restart/reload Dovecot once a week via a cron job. Letsencrypt will renew certs with less than 15 days to go, so once a week should catch it.
If you're using Let's Encrypt, then at least the certbot client has renewal hooks that you can use to run dovecot reload etc.
Good luck! Reio
I have to say I'm totally baffled since I do nothing when LetsEncrypt renews the certificate.
I know the cert has been updated because the mail clients asks me if I trust the certificate.
If it makes a difference I use the bash LetsEncrypt not the Python code.
Original Message From: reio@mrstuudio.ee Sent: October 9, 2020 1:55 AM To: dovecot@dovecot.org Subject: Re: Feature request.
On 09/10/2020 11:50, Plutocrat wrote:
On 09/10/2020 4:16 pm, Rogier Wolff wrote:
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th. I guess you could do a few things yourself to make sure the cert is valid. Thinking out loud:
- Blunt instrument approach: Just restart/reload Dovecot once a week via a cron job. Letsencrypt will renew certs with less than 15 days to go, so once a week should catch it.
If you're using Let's Encrypt, then at least the certbot client has renewal hooks that you can use to run dovecot reload etc.
Good luck! Reio
On 09/10/2020 12:52, lists wrote:
I have to say I'm totally baffled since I do nothing when LetsEncrypt renews the certificate.
I know the cert has been updated because the mail clients asks me if I trust the certificate.
Curious. The mail clients really shouldn't ask anything when encountering a valid certificate.
Are you sure the client isn't asking you to trust an expired certificate?
Reio
I have to say I'm totally baffled since I do nothing when LetsEncrypt renews the certificate.
I know the cert has been updated because the mail clients asks me if I trust the certificate.
If it makes a difference I use the bash LetsEncrypt not the Python code.
I don't like all those dependencies certbot (python) installs, but it works flawlessly on CentOS. On CentOS 8 you need to enable the EPEL *and* PowerTools repositories (/etc/yum/repos.d/...)
I've attached a small perl script that I call via cron 30 minutes after certbot starts which reloads services if necessary.
Best regards Gerald
#!/usr/bin/perl
my $reload;
open(FF, "find /etc/letsencrypt/live -mtime -1 -name cert.pem |"); while(<FF>){ chomp; next if !$_; $reload++; } close(FF);
if($reload){ system("/usr/bin/systemctl reload httpd"); system("/usr/bin/systemctl reload postfix"); system("/usr/bin/systemctl reload dovecot");
}
On 09/10/2020 14:02, Gerald Galster wrote:
I have to say I'm totally baffled since I do nothing when LetsEncrypt renews the certificate.
I know the cert has been updated because the mail clients asks me if I trust the certificate.
If it makes a difference I use the bash LetsEncrypt not the Python code. I don't like all those dependencies certbot (python) installs, but it works flawlessly on CentOS. On CentOS 8 you need to enable the EPEL *and* PowerTools repositories (/etc/yum/repos.d/...)
I've attached a small perl script that I call via cron 30 minutes after certbot starts which reloads services if necessary.
Best regards Gerald
#!/usr/bin/perl
my $reload;
open(FF, "find /etc/letsencrypt/live -mtime -1 -name cert.pem |"); while(<FF>){ chomp; next if !$_; $reload++; } close(FF);
if($reload){ system("/usr/bin/systemctl reload httpd"); system("/usr/bin/systemctl reload postfix"); system("/usr/bin/systemctl reload dovecot");
}
With certbot you can simply put a script in /etc/letsencrypt/renewal-hooks/deploy/:
# deploy-hook-script.sh
set -e
for domain in $RENEWED_DOMAINS; do case $domain in
domain.com ) chmod 600 "$RENEWED_LINEAGE/fullchain.pem" chmod 600 "$RENEWED_LINEAGE/privkey.pem" /usr/bin/systemctl reload dovecot /usr/bin/systemctl restart opensmtpd ;;
esac done
so if you have a new certificate it is valid vor 89.something days, you could do a:
openssl x509 -in file.crt -checkend 7689600 -noout > /dev/null && /usr/bin/systemctl reload dovecot
Automatic renewal
The Ubuntu package for certbot comes pre-configured with systemd timer that will automatically renew existing certificates. What it does not handle however is reloading postfix/dovecot so that they will begin using the new certificates. For that, we need to implement a hook.
Certbot has both pre and post hooks that you can use to execute a script prior to and after the renewal process. It also has a renew hook that is run whenever a certificate is successfully renewed.
Both the renew hook and post hook are good candidates for our reload script. Each has a downside however. The post hook will be run after every renewal attempt, regardless of if anything was actually renewed or not. This will result in the services being reloaded many times for no reason.
The renew hook only runs if a certificate was successfully renewed, but it will be run once for each certificate. This could mean reloading services multiple times if you have multiple certificates. If you only have a single certificate however it'll work great.
In my case I only have a single certificate, so the renew hook is what I'm going to use. To setup the hooks a configuration file for certbot needs to be created at /etc/letsencrypt/cli.ini. The configuration file consists of simple name=value pairs where the name is taken from the list of command line parameters.
To configure a renew hook, add the following to the configuration file:
renew-hook = /root/bin/certbot-renew Next, create the renew hook script at /root/bin/certbot-renew with the following contents:
#!/bin/sh systemctl reload postfix systemctl reload dovecot
Sent from my iPhone
On Oct 9, 2020, at 04:17, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
Hi,
I get my Email from my own SMTP server on the internet using "fetchmail". Some time ago I did the smart thing and configured dovecot to use SSL and the letsencrypt certificate that automatically renews.
Welllll..... a few days ago my certificate expired and the fetchmail deamon running in the background had nowhere to complain. So I didn't notice.
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th.
So.... Feature request: check the expiry date on the SSL certificate as it is being loaded and check for a new certificate if it HAS expired.
If you worry about performance, this could be done where:
TLS handshaking: SSL_accept() failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45
is reported. That would mean that ONE client will once get the error before dovecot fixes it. My personal fix is to restart dovecot once a week from now on.
I might be running an older version:
# 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.21 (92477967) # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 LTS
if it has already been fixed, please accept my apologies.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
On Fri, Oct 09, 2020 at 07:55:53AM -0400, David Morsberger wrote:
To configure a renew hook, add the following to the configuration file:
renew-hook = /root/bin/certbot-renew Next, create the renew hook script at /root/bin/certbot-renew with the following contents:
#!/bin/sh systemctl reload postfix systemctl reload dovecot
My suggestion is that you make a /etc/certbot/reload-hooks/ directory and then use run-parts /etc/certbot/reload-hooks/ as the hook
and put
#!/bin/sh systemctl reload postfix
#!/bin/sh systemctl reload dovecot
as separate scritps in there.
Now, postfix can come with its own /etc/certbot/reload-hooks/010-postfix and similar for dovecot.
And certbot can start shipping with an empty directory and that run-parts preconfigured!
Now all that's left is to submit this to the various maintainers so that we don't have to do this manually every time a reinstall happens.
Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
On Fri, 9 Oct 2020, David Morsberger wrote:
Both the renew hook and post hook are good candidates for our reload script. Each has a downside however. The post hook will be run after every renewal attempt, regardless of if anything was actually renewed or not. This will result in the services being reloaded many times for no reason.
An alternative to using certbot hooks is to use an inotify based tool (available for most Linux based OS). A certificate update triggers a restart script. For example,
https://linux.die.net/man/5/incrontabThe renew hook only runs if a certificate was successfully renewed, but it will be run once for each certificate. This could mean reloading services multiple times if you have multiple certificates. If you only have a single certificate however it'll work great.
For this case, I think you need a periodic (cron) process, restart rather than a synchronous process, that will check certs and restart/reload once per day/week/whatever. This is the method I use as my LE certificates are obtained via DNS challenges on a different host.
Joseph Tam jtam.home@gmail.com
On 09 Oct 2020, at 02:16, Rogier Wolff R.E.Wolff@BitWizard.nl wrote:
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th.
The ACME protocol that LE uses has a specific feature for specifying a script to run after a certificate updates. One of the common things to do in these scripts is to restart services like apache and dovecot so they see the new certs. Other common actions are copying the certs to specific locations on the system (like, say, into jails) or even to other hardware.
This is the best, most reliable, and least fiddly solution.
-- SHERRI DOES NOT "GOT BACK" Bart chalkboard Ep. AABF07
Le 10 oct. 2020 à 11:38, @lbutlr kremels@kreme.com a écrit :
On 09 Oct 2020, at 02:16, Rogier Wolff R.E.Wolff@BitWizard.nl wrote:
It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th.
The ACME protocol that LE uses has a specific feature for specifying a script to run after a certificate updates. One of the common things to do in these scripts is to restart services like apache and dovecot so they see the new certs. Other common actions are copying the certs to specific locations on the system (like, say, into jails) or even to other hardware.
This is the best, most reliable, and least fiddly solution.
ACME protocol does not care about script run on renew, as it only specifies the network exchange between the ACME client and the ACME server. Running hook on script renew is the responsibility of each acme client, and so is specific to the client you are using.
All clients have there own way to do it:
- certbot.
- acmebot
- acmetool (which may be a good solution for people who don’t like dependencies installed by other solutions as this is a standalone binary)
- Kubernetes CertManager.
Just check the doc for the one you are using.
- Rogier Wolff:
a few days ago my [Let's Encrypt] certificate expired and the fetchmail deamon running in the background had nowhere to complain. [...] Feature request: check the expiry date on the SSL certificate as it is being loaded and check for a new certificate if it HAS expired.
That's not something Dovecot needs to worry about. You did not specify what mechanism you use to update your certificates, but both certbot and duplicity (likely the most common tools for Linux) support post-update hooks that let you automatically reload/restart Dovecot whenever a certificate update occurs.
-Ralph
participants (13)
-
＠lbutlr
-
Aki Tuomi
-
David Morsberger
-
Gerald Galster
-
infoomatic
-
Jean-Daniel
-
Joseph Tam
-
lists
-
Marc Roos
-
Plutocrat
-
Ralph Seichter
-
Reio Remma
-
Rogier Wolff