Issue
After updating the JVM used by my CI instance, we started to see the following error message in the logs, and my CI instance doesn’t send emails:
java.security.cert.CertificateException: No subject alternative DNS name matching XXXXXXXXXXXXX found. at java.base/sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:212) at java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:103) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:462) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:418) at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:238) at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)
Cause
Since Java 1.8.0 181 version, the endpoint identification algorithms have been enabled by default:
Thus, in case we have a certificate covering an SSL/TLS connection and we don’t have the certificate for the hostname correctly configured (the subject is not correctly set, or the hostname is not present in the alternatives), we can start to find a CertificateException related to name matching when we connect external resources (which are covered by this SSL/TLS connection).
Why did the same certificate setup not fail before the JVM upgrade? Before Java 1.8.0 181 version, the endpoint identification algorithms were not enabled by default. Thus the JVM was not checking the match between the external hostname and the subject (and alternative) found in the public key covering the SSL/TLS connection.
Resolution
The ideal solution to this problem is to modify the certificate to match correctly the external hostname. In order to get this done, you might need to contact your Security Team and ask them to install a new certificate in the external hostname to match correctly the endpoint.
Workaround
However, it is possible you cannot apply the above solution (or you need a temporal solution while the above is being accomplished). In this case, you could try to use a Java argument to disable the endpoint identification algorithms checker in the JVM. You must add the proper Java argument and restart the Jenkins instance to apply the changes.
If you are observing these exceptions when the instance is trying to send emails, you can try the argument below to workaround the issue:
-Dmail.smtp.ssl.checkserveridentity=false
On the other hand, if you are observing these exceptions while accessing your LDAP server, the argument should be:
-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true
The necessary Java argument could be different depending on the protocol. So, you need to check how to disable the endpoint identification algorithms in Java depending on the protocol used when observing this kind of exception.