When sending a letter in Mozilla Thunderbird, I received a message that "mail.kr-labs.com.ua:465 does not have a valid certificate". But the certificate was updated with certbot:
Postfix on port 465 is stubbornly issuing the previous expired certificate, although /etc/postfix/main.cf contain locations of the certificates provided by LetsEncrypt. I am completely confused. Is this a bug, or is it an error on my servers side?
My os and web server: CentOS 7, OpenLiteSpeed 1.8.2
The problem is with SNI.... But why - I can't give an exact answer yet...
I just commented on the line #tls_server_sni_maps = hash:/etc/postfix/sni_map and OpenSSL saw a valid certificate:
openssl s_client -connect mail.kr-labs.com.ua:465 -servername mail.kr-labs.com.ua -showcerts
CONNECTED(00000003)
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 = R11
verify return:1
depth=0 CN = mail.kr-labs.com.ua
verify return:1
---
Certificate chain
0 s:CN = mail.kr-labs.com.ua
i:C = US, O = Let's Encrypt, CN = R11
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Feb 13 16:36:47 2025 GMT; NotAfter: May 14 16:36:46 2025 GMT
Now I'm going to figure out where the configuration error was made in SNI. Although, up to a certain point, everything worked fine with the old configuration.
Hm, thank you for the guide. Most helpful for future readers
However, I still don't understand what went wrong with your Postfix configuration when Certbot renewed the cert(s). Did the SNI mapping differ than what was expected? Is a postmap -F required every time one renews a cert? Does any Postfix command be added to a --deploy-hook so it fixes Postfix every time a cert gets renewed?
(I don't use the SNI mapping personal, so I don't have experience with it.)
Main reason - some inaccuracies in Postfix configuration, in particular SNI configuration. Because, all problems disappeared after the SNI was correctly configured.
# Add deploy hook for certbot renewals to apply to Postfix
# Create the reload-postfix.sh file
echo '#!/bin/bash' > /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh
echo '' >> /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh
# Add the desired commands
echo 'postmap -F /etc/postfix/vmail_ssl.map' >> /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh
echo 'systemctl restart postfix && systemctl restart dovecot && systemctl restart opendkim' >> /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh
# Make the script executable
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh
echo "Script 'reload-postfix.sh' has been created and configured."
In fact, this is the same as I emphasized above. IMMEDIATELY after receiving the certificates, you need to perform a COMPREHENSIVE UPDATE in Postfix itself, and most importantly - SNI MAP. And then there will be no such problems).
Certbot automatically executes scripts placed in the directory /etc/letsencrypt/renewal-hooks/deploy/ after the certificates are successfully renewed.
You can verify that Certbot is successfully running these scripts by viewing the Certbot log files (if configured) or by adding logging to the script itself (as in the example with writing the date to /var/log/letsencrypt/renew-hook.log).
Thus, you do not need to manually run this hook - it will be executed by Certbot during the renew process.
Unlike most of the hashed maps, the contents of /etc/postfix/vmail_ssl.map are determined by reading the contents of a file, rather than the file being reread dynamically. That file must be reread and the "*.db" file must be recreated when contents (your certificate) change. Using the deploy hook is a decent way to handle that problem.
