Postfix (seems to be) reloading, but not Dovecot

I've had certbot running on this mailserver that I'm running, and it seems that when the certificate is renewed that Postfix continues to run just fine, but Dovecot starts throwing certificate errors (and blocks iPhone access).

Where do I poke the bear to fix this?

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: NA

It produced this output: NA

My web server is (include version): NA.

The operating system my web server runs on is (include version): Linux

My hosting provider, if applicable, is: Myself.

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.40.0

Well, it would be helpful to actually see some information to work with. "Dovecot starts throwing errors" doesn't help at all. Crystal balls are only a real thing in fiction I'm afraid.


That was a bad way to put it. Sorry.

Dovecot doesn't actually start throwing errors, IMAP clients start complaining about expired certificates. I then log in and do a systemctl restart dovecot and the problem goes away.

It appears that Postfix is being restarted, but that Dovecot isn't.

Honestly this last happened in January, and I was really busy at the time so I just restarted it and went on my way. The evidence in /var/log/mail is gone, and there's nothing in the letsencrypt logs about restarting either.

Where would that configuration be?

We're due for a renewal in 6 days, so I can just wait for that to happen to gather log data.

1 Like

Depends on how you've set you system up to reload Postfix. Did you add a deploy hook to Certbot at time of issuance? Or did you edit the cronjob/systemd timer or did you add your own cronjob/systemd timer?


I did apt install certbot python3-certbot-apache and that's pretty much where my notes--and memory end for this.

There's an /etc/systemd/system/

and there's nothing in /etc/letsencrypt/renewal-hooks.

So should I assume that neither postfix nor dovecot are restarting, and create some post-hooks?

Side note:

That is an old version of Certbot see Certbot 2.3.0 Release

1 Like

Why the h* is Ubuntu 20.04 LTS so far behind?

I'm maintaining this for a friend, and trying really hard not to make this a frankenserver.

Even 22.04 is on 1.18.


Deploy hooks can also be found in the corresponding renewal configuration file of the certificates. It would be called renew-hook I believe for some reason though in the file itself :roll_eyes:


That's just how linux distributions work. They may update versions during the active support window, but usually do not. Essential security releases will get pushed out during the active support and extended windows. Realistically, you shouldn't expect updates on most packages after the release is finalized.

Because of this, the Certbot team initially worked with distributions to fast-track releases - but that was too much work. A few years ago, they dropped direct support for distribution and moved primary support to snapd distribution. The best option to keep certbot up-to date on linux distributions is to use snap.

In terms of renewal, if you upgrade to the most recent version there is a new 'reconfigure' command which should allow you to edit a hook

The renewal hooks documentation has long needed improvement. See Clarify and expand renewal-hook documentation · Issue #5935 · certbot/certbot · GitHub.


Some distributions. E.g., Gentoo works quite differently (rolling release).


Now that reads better!


Yeah, I've been using Linux for a really long time, I didn't realize that Certbot was versioning that quickly.

Certbot, like Ubuntu, has moved to snap apps as their preferred distribution mechanism. I'm not yet willing to install snapd on servers, but it will get you into current versions of Certbot.


If snapd isn't an option (e.g. understandable objections of principle) you can always use the pip instructions (using a virtual environment! as instructed in the Certbot pip documentation).


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