Since April 30, I'm seeing errors like that in my mail log:
May 1 02:27:27 afaron postfix/smtpd: connect from r137.info.hofer.at[188.8.131.52]
May 1 02:27:27 afaron postfix/smtpd: SSL_accept error from r137.info.hofer.at[184.108.40.206]: -1
May 1 02:27:27 afaron postfix/smtpd: warning: TLS library problem: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired:../ssl/record/rec_layer_s3.c:1543:SSL alert number 45:
May 1 02:27:27 afaron postfix/smtpd: lost connection after STARTTLS from r137.info.hofer.at[220.127.116.11]
May 1 02:27:27 afaron postfix/smtpd: disconnect from r137.info.hofer.at[18.104.22.168] ehlo=1 starttls=0/1 commands=1/2
As far as I can grasp it, r137.info.hofer.at[22.214.171.124] refuses to send mail to my server, because it claims my SSL certificate would be expired.
I double-checked if the latest issed letsencrypt certificate one is actually used by postfix, and it is (via the live symlink – the server has been running for almost a year now without any problems). It's not expired. I even tried to force-update the cert, but the errors re-appeared. When I run openssl s_client -starttls smtp -showcerts -connect mail.l3u.de:25 -servername mail.l3u.de , I get a valid TLS session ticket.
The issue you could see is with android < 7.1.1 clients, if you use the same certificate for port 25 and for the "client" ports (110, 143, 465, 587, 993, 995).
If there are mailservers around that haven't been updated since 2015, I am not sure I want to get mail from them. And they'll probably react like this one, if the certificate is expired and they do not ignore the expiration.
In practice, I found this a few days ago, when I started to thoroughly look into that technology and built a test environment.
The problem with the "expired cert" arises only and specifcally when both sides use Let'sEncrypt certs.
And it arises with very new software.
What should happen to the mailserver? What is worrying You?
Technically we call this a false positive (or false negative, as you want it): the certificate is flagged as untrustworthy although it is trustworthy. So what can happen is, communication does fail, and you don't get your mail.
And then you start reading the sourcecode evilgrin
I did, I read the code of sendmail (it's beautiful), and the bug was not there.
Now I assume it is in openssl. Interesting that You say it suddenly appeared a few days ago. Then it could be a regression.
Could You figure out what exactly has been changed/upgraded at that time?
I don't remember option. I do remember what is in the files:
Alice uses a Let'sEncrypt cert. Bob has the expired DST X3 caroot in his root store, and the DST intermediate in his(!) chain. Kabumm!
It doesn't matter what certificate Bob actually uses.
I assume this is a bug where the local chain-data for authentication spills over into the chain-data for verification, inside of openssl.
To me this makes a lot of sense, because it is quite typical for bugs that were fixed, but forgot a corner-case.
The option? Maybe you mean the --preferred-chain? That nice for automation, but technically doesn't matter much, because I can as well take an editor and delete the offending cross cert out of the chain-file. The effect is the same: as soon as Bob does not have the DST internediate in his chain-file, the error is gone.