Jira DVCS and Gitlab integration is broken with "javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching some.host.name.com found"
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
In this article we are going to describe a scenario where Jira DVCS integration with Gitlab is not working with error "javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching some.host.name.com found"
1
2024-11-05 03:35:42,528-0800 https-jsse-nio-8443-exec-13 ERROR user1 215x186x1 1n18w90 1.2.3.4 /rest/oauth2-client/latest/config/flow/abcd1234-5678-9abc-d321-456abc1abcd12 [c.a.o.c.rest.resource.ClientConfigurationResource] Error occurred while authorizing an integration. The error message is: javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching some.host.name.com found.Environment
Jira Data Center 9.x
Diagnosis
This error "No subject alternative DNS.." often arises when the certificate does not include a Subject Alternative Name (SAN) that matches the domain you're trying to reach. Hence, this error is generally seen with the SSL certificate configurations and not with integration between Jira DVCS and Gitlab.
Reference Atlassian articles on this topic:
We can get the SAN details from keystore with
keytoolcommand. For example, we expect similar details in output. This hostname, some.host.name.com, is used as a placeholder for a GitLab setup:
1
2
3
4
5
6
7
8
$ keytool -list -v -keystore samplekeystore.jks
........
#8: ObjectId: 1.2.3.4 Criticality=false
SubjectAlternativeName [
DNSName: some.host.name.com
DNSName: www.some.host.name.com
]
........We can use
openssl s_clientcommand to debug SSL/TLS connections. It initiates a client-side SSL/TLS connection to a remote server. In this output it is expected that CN value should be same as SAN:
1
2
3
4
5
6
7
8
$ openssl s_client -connect some.host.name.com:443
........
Server certificate
----BEGIN CERTIFICATE----
........
----END CERTIFICATE----
subject=/C=sampleCountry/ST=sampleState/L=sampleLocality/O=sampleOrg/CN=some.host.name.com
........Cause
When we execute the
openssl s_clientcommand from host where Jira was installed, in the output we may find a different hostname in value of CN:
1
2
3
4
5
6
7
8
$ openssl s_client -connect some.host.name.com:443
........
Server certificate
----BEGIN CERTIFICATE----
........
----END CERTIFICATE----
subject=/C=sampleCountry/ST=sampleState/L=sampleLocality/O=sampleOrg/CN=different.host.name.com
........In the output of
openssl s_clientcommand, a different CN value different.host.name.com was found, however expected value was some.host.name.com.Later same openssl s_client command can be executed from one of the hosts where Jira is not installed. In the output correct CN value may be found
This verifies that the reason for the "No subject alternative DNS name matching some.host.name.com found" is indeed due to a misconfiguration
Solution
Please contact your IT/Infra/network team in order to address this routing problem.
Was this helpful?