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).

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.