0

This question already has an answer here:

I've been running a Postfix/Dovecot mailserver for some time now (Ubuntu server 16.04), without any major issues. I also have a Let's Encrypt certificate issued to my hostname, which I setup in /etc/dovecot/conf.d/10-ssl.conf. That was running fine but as you may know those are only valid for 90 days. I have certbot setup to renew these automatically, which is also working fine.

Suddenly, today, both my Thunderbird, a clients Thunderbird and his iPhone started to complain about invalid certificates. I checked the certificates through certbot certificates to find out that the certificate I use was totally valid, not expired. Inspecting the certificate through Thunderbird told me the certificate had expired the day before, showing me a hash that did not match the current certificate.

So basically, it seems like Dovecot is issuing an expired certificate from some kind of 'cache'. Restarting dovecot just 'magically' fixed it but I'd like to understand what happened here since my DDG searches on certificate caches or alike in Dovecot didn't get me any results. Am I missing something obvious here? It seems like I've overlooked something obvious but can't figure out what.

EDIT This is basically answered here but since my certbot renews on a systemctl timer in stead of a cronjob I will try to provide the answer for that situation here for future reference and anyone in the same boat as I am.

marked as duplicate by Gerald Schneider, bodgit, Jenny D says Reinstate Monica, wazoox, Ward - Reinstate Monica Mar 21 at 15:29

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • @GeraldSchneider You may be right! It seems that this answer (serverfault.com/a/868919/501683) is what I need. I never knew Dovecot wouldn't pick up on this automatically. Let me try it and answer my own question with my findings. – Guido Goluke Mar 13 at 14:28
  • Just confirm if it is the case and the question can be closed as a duplicate. No need for redundant answers. – Gerald Schneider Mar 13 at 14:31
  • It is the case, but since my auto-renewal is not through a cronjob but through a timer and the mechanism is a bit different, I will mark it as duplicate but still try to answer it myself using your other answer but tailored to my situation for future reference and anyone else who has the same setup. – Guido Goluke Mar 13 at 15:07
1

This is basically the same problem as answered here by Gerald Schneider. However, since my setup does not rely on a cronjob but on a system timer the answer differs slightly.

Let's Encrypt will, at least on Ubuntu let you create a hooks in when the automatic renewal runs through a timer (check that using systemctl list-timers and see if it's there).

There are basically two events you can hook into: deploy and post. Place your bash-scripts in the /etc/letsencrypt/renewal-hooks/deploy or /etc/letsencrypt/renewal-hooks/post folders respectively. Deploy will run on each certificate renewal individually, post will run after all renewal is done.

The deploy script does have access to both the $RENEWED_DOMAINS and the $RENEWED_LINEAGE variables. I placed the following script in etc/letsencrypt/renewal-hooks/deploy:

  1 #!/bin/bash
  2 for domain in $RENEWED_DOMAINS
  3 do
  4         if [ "$domain" = my.mailserver.com ]
  5         then
  6                 doveadm reload >/dev/null
  7         fi
  8 done

Which will reload the dovecot conf every time the certificate for 'my.mailserver.com' (obviously replace that with a real domain) gets re-deployed. Hope this helps anyone that was looking for this.

Not the answer you're looking for? Browse other questions tagged or ask your own question.