4

I have an email server where I have Let's Encrypt SSL certs, expiring every 3 months, and certbot automatically renews it. If I access the server through a website in the browser, the correct and newest SSL certificate is used, but thunderbird complains that the SSL certificate is not valid, by that it has expired.

The complaint is displayed through a dialog window, and if I click to view the certificate through this window, it shows an old certificate that has indeed expired. However, if I click the button "Get certificate", that button itself grays out, but nothing else happens. I tried right-clicking the name of the e-mail address (account) in thunderbird, and going to Settings -> Security and deleted all the certificates for the domain, but somehow still it has the old stored certificate stored.

My setup is dovecot + postfix.

Any ideas?

simernes
  • 185

6 Answers6

6

Thunderbird does not access the mail using the same server as the browser does. The browser accesses a web server using HTTP/HTTPS while Thunderbird accesses a mail server using the IMAP/IMAPs or POP3/POP3s protocol for receiving mail and the SMTP protocol for sending. These are separate servers with separate configuration, which means that they need to be configured to use the appropriate certificates in the first place and that they must also be restarted when the certificates got renewed.

While it is impossible to say what your specific setup includes (EDIT: after an edit of the question it got clear that it is the setup I've described), a common setup is to use dovecot for receiving mail and postfix for sending. So you might try to look at these software and configurations on your (unknown) system and make sure that these get updated and restarted whenever the certificates change.

Steffen Ullrich
  • 6,047
6

Dovecot may need to be reloaded. I had exactly that case with Postfix+Dovecot+certbot. Certbot was showing the certificate is already renewed, but still the server was using expired certificate. I was able to see that by testing with openssl (Ubuntu):

openssl s_client -connect mydomain.com:993 -quiet
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mydomain.com
verify error:num=10:certificate has expired
notAfter=Dec  5 15:42:11 2020 GMT
verify return:1
depth=0 CN = mydomain.com
notAfter=Dec  5 15:42:11 2020 GMT
verify return:1
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE  AUTH=CRAM-MD5 AUTH=LOGIN AUTH=PLAIN] Dovecot (Ubuntu) ready.
^C

Reload Dovecot:

sudo service dovecot reload

That was enough to fix it in my case. Still it may be worth checking whether reboot is requested for the server:

ls -l /var/run/reboot-required
ajaaskel
  • 241
  • 3
  • 3
1

I've observed a similar issue when connecting to an letsencrypt-enabled SMTP server (postfix) using the submission port 587 with STARTTLS. After an hour of debugging I found out that Thunderbird leveraged TLS Session Resumption and therefore did not perform a full TLS handshake, hence the new certificate had not been sent by the server. I'm not sure yet whether this is a bug in TB or a misconfiguration on server side - as for now I've set session expiration time to 0s on server side (thus actually disabling server side session caching) and restarted postfix, which instantly solved the issue.

Based on that configuration, TLS sessions should now be stored client side in respective session tickets. However, I've not found out yet where these are stored and how to flush the cache. Flushing the cache should be the absolute key to solve that issue.

xof
  • 11
0

I had experienced this issue twice.

I run a CentOS (Stream) with postfix, dovecot, amavisd, mysql, clamd, spamassassin, selinux, opendkim, opendmarc and letsencrypt / certbot.

I have 3 email domains and a number of web domains so I have separate certificates for each domain and server that certbot renews automatically just fine.

However, because I am using sni_maps (check postifx), when the certificate gets replaced by certbot, while postfix may restart / reload, the sni_map.db file needs to be recreated with postmap -F otherwise the certificate will not be updated.

Robert Heller
  • 11
0

Thanks to Robert Haller answer I managed to fix this. If anyone is stuck on this issue with Thunderbird not seeing the new and valid certificates and have the same setup with dovecot postfix and certbot, with multiple mail servers on their VM, you probably use sni.map which need to be remapped after certificate update. So the solution for me was:

postmap -F hash:/etc/postfix/sni.map
wsott
  • 1
0

This is a little old, but I have run into this problem also. It was in regard to postfix and postmap.

What happened for me was in vim /etc/postfix/sni_map url was not pointing to the proper letsencrypt certs because letsencrypt wasn't done at first for my system

ex in my/etc/postfix/sni_map (using a newer postfix with debian 11)

domain.ca     /home/domain/ssl.key,/home/domain/ssl.cert,/home/domain/chain.pem    
.domain.ca
/home/domain/ssl.key,/home/domain/ssl.cert

even thought this was setup with all three certs, you can do this with letsencrypt

domain.ca  /etc/letsencrypt/live/domain.ca/privkey.pem,/etc/letsencrypt/live/domain.ca/fullchain.pem
.domain.ca /etc/letsencrypt/live/domain.ca/privkey.pem,/etc/letsencrypt/live/domain.ca/fullchain.pem

then for the db, you can regenerate with

postmap -F hash:/etc/postfix/sni_map

And reload or restart postfix (I forget if reload works)

systemctl restart postfix
gstlouis
  • 29