Dovecot / postmap / postfix requires manual restart after certbot update (every 3 mos!)

The cert I use for dovecot, SMTP, and proftpd is an LE cert. Every time it updates, I have to restart Dovecot or it eventually expires in the running version. Why isn’t this happening automatically?

On the “SSL Certificates” page for the domain I use for those services, it says:

Used by services Webmin (domain.xxx), Usermin (host domain.xxx), Dovecot (global), Postfix (host domain.xxx), Postfix (global)

But every three months I get an “expired cert” error on IMAP clients, and have to manually restart dovecot?

Additionally, it seems that a restart of postfix was insufficient to fix the outgoing (SMTPS) certificate. That required a “postmap -F hash:/etc/postfix/sni_map” in addition! Some kind of cert caching? Why have I never had to do this before?

SYSTEM INFORMATION
OS type and version ubu 20.04
Webmin version 2.001
Virtualmin version 7.3-1 Pro
Related packages dovecot

@creeble,

This might be a bug, so let’s see what @staff have to say about this.

That’s odd, because the current code does tell Dovecot and Postfix to re-read their config files after SSL cert renewal.

What command are you running to do the manual restart?

I’m doing a full “service dovecot restart”, which worked for that, but the same for postfix was insufficient - i had to do the “postmap -F hash:” thing or smtpd would still serve the expired cert.

The certs were replaced correctly and automatically. I do not have certbot installed (other than whatever virtualmin installs).

Perhaps, to apply global certificate you need to fully restart the service, instead of reload? Also, I read few posts on StackOverflow where other people reported the same problem, saying that reload didn’t work but restart fixed the problem.

Ok, I will update Virtualmin to fully restart Postfix and Dovecot in this case…

Well, again, that was insufficient for me – I restarted postfix several times and wondered why it (STMP via port 587 STARTTLS) was still delivering an expired cert.

Then I found:

which fixed it when I ran postmap -F hash:/etc/postfix/sni_map AND restarted postfix.

Ah ok … Virtualmin will run postmap on the sni_map, but won’t restart Postfix on a cert file update. I’ll add that.

1 Like

I think it needs both – postmap on the sni_map, AND a restart of postfix. Maybe it only needed a reload of postfix config after the postmap, but I did a restart (and without the restart it was still caching the old cert).

@Jamie @creeble @Ilia,

Unless the paths mentioned in the “sni_map” file have changed, you DO NOT need to re-run postmap against that file.

As suggested in the Let’s Encrypt community at:

A way to address the matter would be to “restart” Postfix (SMTP) and Dovecot (POP/IMAP) after the renewal completes.

*** If the file path changes which I highly doubt it would, then and only then a run of postmap would be needed. This is the basis of any file managed by postmap ***

An interesting idea from the above post on LE Community is to add the restart as part of the “–post-hook” or “–deploy-hook” via the CertBot command.

*** Affordable, Professional, Trusted Technical Assistance – tpnAssist.com ***

2 Likes

Thank you for the heads up, Peter. We will do this on the new release!

Happy New Year! :santa:

2 Likes

Well, that conflicts with my experience and the posting at:

which had a postmap fix a renewal issue, just as I experienced. I don’t know if the file location changed, but the renewal happened without my interaction (and I did not install certbot in any way other than what the standard virtualmin install does).