How to Resolve "No Subject Alternative DNS Name Matching Hostname" SSL Error in Jira
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Connection from JIRA to LDAPS (LDAP with SSL enabled) fails with the exception:
java.security.cert.CertificateException: No subject alternative DNS name matching <hostname> found.
Diagnosis
The following appears in atlassian-jira.log
:
com.atlassian.crowd.exception.OperationFailedException: java.util.concurrent.ExecutionException: com.atlassian.crowd.exception.OperationFailedException:
org.springframework.ldap.PartialResultException: nested exception is javax.naming.PartialResultException
[Root exception is javax.naming.CommunicationException: simple bind failed: <hostname>:636
[Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching <hostname> found.]]
OR
nested exception is javax.naming.CommunicationException: <hostname>:636
[Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching <hostname> found.]
One or more of the following scenarios may apply:
The LDAP server hostname has changed but it's still using an old SSL certificate that refers to the old hostname
JIRA and/or Java has recently been upgraded/updated whereby JIRA is now using Java version 1.8.0_181 or above
There are a bunch of LDAP servers in the same forest that can communicate with one another with Follow Referrals enabled
Cause
Cause 1
According to CWD-2690, JIRA now verifies if the CN/SANs of the SSL certificate matches the hostname of the LDAP server. If there's a mismatch, JIRA will fail the connection and throws the above error. For example:
LDAP server hostname is ldapserver.com
CN/SANs of SSL certificate is jiradirectory.com
JIRA is using ldapserver.com to connect to LDAP, which differs from jiradirectory.com
Cause 2
JIRA is connected to LDAP server 1 with Follow Referrals enabled. With this configuration, LDAP server 1 may attempt to communicate with LDAP server 2 that may have a different hostname and/or SSL certificate, causing an unexpected mismatch.
Solution
For Cause 1
Workaround 1
Edit the hosts
file in the JIRA server and map the CN of the SSL certificate to the IP address of the LDAP server. Then connect JIRA to LDAP using that CN.
Following the example in Cause 1 section:
Map jiradirectory.com to the IP address of the LDAP server
Connect JIRA to LDAP using jiradirectory.com instead of ldapserver.com
Workaround 2
Disable Secure SSL by editing the LDAP directory and unchecking that box from Advanced Settings.
If JIRA is using Java 1.8.0_181 or above (refer to JRASERVER-66241), the following JVM parameter must also be set following Setting properties and options on startup:
-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true
Refer to JDK 8u181 Update Release Notes for more details on this.
For Cause 2
Disable Follow Referrals by editing the LDAP directory and unchecking that box from Advanced Settings.
Resolution
This applies to Cause 1 only
Fix the SSL certificate to contain the right LDAP server hostname (recommended and most secure)
Was this helpful?