Our secure SMTP connection to an external site began failing on 4/22. The error message indicated an issue somewhere in the certificate chain.
[java:java:ERR /1:to_RHIO_direct_0:--/--/---- --:--:--] org.springframework.mail.MailSendException: Mail server connection failed; nested exception is javax.mail.MessagingException: Could not convert socket to TLS;
[java:java:ERR /1:to_RHIO_direct_0:--/--/---- --:--:--] nested exception is:
[java:java:ERR /1:to_RHIO_direct_0:--/--/---- --:--:--] javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: com.ibm.security.cert.IBMCertPathBuilderException: unable to find valid certification path to requested target. Failed messages: javax.mail.MessagingException: Could not convert socket to TLS;
We make the connection first, then issue Start TLS. This has been working without problems for over two years. Two years ago, maybe 27 months ago, we had a similar issue - same exception in the log. I did not keep records of that issue but I remember that the digital certificate had an expiry date that was one week in the future - that is, it should have been working for one more week before any problems arose because of expiry. So last time, we got a new certificate and the problem was resolved. So this time, I observed the same circumstance. The expiry date on that certificate was for 4/29/2022:
Keystore type: jks
Keystore provider: IBMJCE
Your keystore contains 2 entries
Alias name: (identifying information removed)
Creation date: Mar 13, 2020
Entry type: trustedCertEntry
Owner: (identifying information removed)
Issuer: CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US
Serial number: (identifying information removed)
Valid from: 2/27/20 7:00 PM until: 4/29/22 8:00 AM
So one might say, that is just a coincidence, the certificate is still good for another week and the problem must come from elsewhere. Well, yesterday the vendor sent me an updated version of the same certificate, and when I added it to the truststore, the connection was established successfully. So, the only change I made was to replace the certificate. Possibly there was an issue with a CA higher up in the chain? And the certificate I received referenced a newer version of a CA higher up in the chain? That is all I can think of.. but it is very strange that the same circumstances happened twice and the resolution both times was to replace a certificate that had not yet expired. Is there another explanation? Thank you
CodePudding user response:
Possibly there was an issue with a CA higher up in the chain? And the certificate I received referenced a newer version of a CA higher up in the chain?
Yeah probably. Usually there is not so much 'the certificate' as 'the certificate chain'. What you showed is merely the final certificate in the chain. If any one of the certs in that chain expired on 4/22/22, then, you have your answer.
Alternatively, it's of course possible your server's clock is wildly off (by 7 days).