By accident, I have an expired intermediate certificate at the end of my chain file in my Dovecot server's SSL configuration. It's enough of a problem that my Android e-mail client refuses to use it, although Apple Mail lets it go (??!). Indeed, the expiration just happened hours ago.
openssl x509 -in ... shows:
Serial Number: 13:ea:28:70:5b:f4:ec:ed:0c:36:63:09:80:61:43:36 Signature Algorithm: sha384WithRSAEncryption Issuer: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root Validity Not Before: May 30 10:48:38 2000 GMT Not After : May 30 10:48:38 2020 GMT Subject: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
But this command:
openssl s_client -showcerts -verify_return_error -connect imap.example.com:993
fails to flag the problem (while outputting the expired certificate!). The OpenSSL package version is:
CONNECTED(00000003) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA verify return:1 depth=0 CN = imap.example.com verify return:1
How do I create an OpenSSL verification test to find and flag this? I have searched online already quite a bit and found nothing to address expiration down a few rungs in a public chain. The closest question is: Why is my SSL certificate untrusted on Android? but this only deals with a missing link in a 4-certificate chain. My guess as to why Apple Mail accepts the error is that MacOS has cached its own non-expired version of the same intermediate CA.
On the server, the following:
is now self-signed, so openssl must be silently substituting this one (edit: tested by hiding this cert; the expiration is now detected!) but my goal is to be sensitive enough to detect the Android's complaint. I am on Android 10 but one (May 4) update behind the latest.