Thunderbird issues with postfix and dovecot using lets encrypt

My domain is: smbservices.ca

I have run into this strange problem and have not found a solution online. Thunderbird does not recognize my certificate for mail. I always says expired. I have the proper settings in postfix and dovecot, and have rebooted the services, even the VM.

I also use PHP for connecting to mail $imap = imap_open('{smbservices.ca:143/tls}INBOX', 'user', 'password'); and I get errors in the connection which I have noted here https://stackoverflow.com/questions/78461297/php-imap-open-cannot-make-a-secure-connection-to-a-virtualmin-dovecot-server-on?noredirect=1#comment139162516_78461297

wanted to share the above as I feel this problem is not just thunderbird but maybe I'm doing something else wrong with certs or config

If I do
openssl s_client -connect smbservices.ca:587 -starttls smtp
openssl s_client -connect smbservices.ca:143 -starttls imap

These all seem fine from what I can understand. (Some output below to show dates)

My postfix main.cf holds

smtpd_tls_cert_file=/etc/letsencrypt/live/smbservices.ca/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/smbservices.ca/privkey.pem

dovecot

ssl_cert = </etc/letsencrypt/live/smbservices.ca/fullchain.pem
ssl_key = </etc/letsencrypt/live/smbservices.ca/privkey.pem

These are not overwritten anywhere in the config files which I checked using grep
services are always reloaded when I update certs

browsers are fine

my renew cmd is simply certbot renew, I forget my initial setup, but I am pretty sure it was with --certonly flag

In thunderbird, if I change the port however to 443, it will recognize the certificate, or at least tell me there isn't any problems (both port 587 and 143 give same problem with immediate error like it does not even check, port 443 you can see its checking)

small snippet ex. If I test from my machine directly

louis$ openssl s_client -connect smbservices.ca:587 -starttls smtp
Connecting to 148.59.149.79
CONNECTED(00000005)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R3
verify return:1
depth=0 CN=smbservices.ca
verify error:num=10:certificate has expired
notAfter=Aug 27 17:32:08 2022 GMT
verify return:1
depth=0 CN=smbservices.ca
notAfter=Aug 27 17:32:08 2022 GMT
verify return:1
---
Certificate chain
 0 s:CN=smbservices.ca
   i:C=US, O=Let's Encrypt, CN=R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May 29 17:32:09 2022 GMT; NotAfter: Aug 27 17:32:08 2022 GMT
 1 s:C=US, O=Let's Encrypt, CN=R3
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   i:O=Digital Signature Trust Co., CN=DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---

If I accept what thunderbird says as old cert, everything is working. In my PHP code, if I remove the tls so it connects without security, it is working. So I feel like there is something wrong with my setup.

any advice would be appriciated

thank you

2 Likes

Welcome to the community @gstlouis

I did not study your post in detail. But, when unusual things like that happen you might try updating postmap.

If that does not help you'll probably need to wait for a different volunteer with more postfix / dovecot expertise.

5 Likes

It looks like your server is serving an old certificate. Please check, is your certificate correctly renewed? If yes, you may want to reload/restart the service. You want to automatize this on each successful renewal.

3 Likes

Thanks for sharing. @MikeMcQ
Interesting. I do not have postmap -F hash:/etc/postfix/sni on the server but have

root@web:~# postmap -F hash:/etc/postfix/sni_map
sni_map     sni_map.db

so I tried

root@web:~# postmap -F hash:/etc/postfix/sni_map
postmap: warning: /etc/postfix/sni_map, line 5: open /home/smbservices/ssl.ca: No such file or directory: skipping this entry
postmap: warning: /etc/postfix/sni_map, line 6: open /home/smbservices/ssl.ca: No such file or directory: skipping this entry

so does this means its looking at these certs that do not exist? Should I be deleting these entried from the sni_map? sorry, this is new to me...

What shows?:
certbot certificates

4 Likes

@MikeMcQ
I think it worked. I have went into the sni_map file and changed the lines pointing to my domain to the proper lets encrypt files and it looks to have worked

so what was:

smbservices.ca  /home/smbservices/ssl.key,/home/smbservices/ssl.cert,/home/smbservices/ssl.ca
.smbservices.ca /home/smbservices/ssl.key,/home/smbservices/ssl.cert,/home/smbservices/ssl.ca

I have changed to

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

exec:

postmap -F hash:/etc/postfix/sni_map

did not get errors and TB just continued without error. This did not fix me PHP trying to connect using $imap = imap_open('{smbservices.ca:143/tls}INBOX', 'username', 'password'); problem unfortunately, this error still says
otice: PHP Request Shutdown: TLS/SSL failure for smbservices.ca: SSL negotiation failed (errflg=2) in Unknown on line 0

I don't know anything about that. An openssl test looks good

openssl s_client -connect smbservices.ca:143 --starttls imap
...
Certificate chain
 0 s:CN = smbservices.ca
   i:C = US, O = Let's Encrypt, CN = R10
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep 19 18:58:07 2024 GMT; NotAfter: Dec 18 18:58:06 2024 GMT
 1 s:C = US, O = Let's Encrypt, CN = R10
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
...
5 Likes

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