No Subject Alternative Names
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
Problem
Your Bitbucket backup client or Bitbucket application fails while connecting to a HTTPS URL and throws a No subject alternative names present Java error on the logs.
Possible situations:
1) Backup client fails
The following appears in the Backup client logs (<path/to/backup/client>/log/atlassian-sbc-YYYY-MM-DD-HHMM.log):
1
2
3
4
5
6
7
8
9
$ java -jar bitbucket-backup-client.jar
2014-12-16 18:11:42,929 INFO Initializing
2014-12-16 18:11:44,479 DEBUG HTTP GET https://127.0.0.1:8443/mvc/maintenance, headers: [Accept:[application/json], Authorization:[Basic amVmZjpqZWZm], User-Agent:[Wink Client v1.1.2]]
2014-12-16 18:11:44,479 DEBUG HTTP GET https://127.0.0.1:8443/rest/api/latest/application-properties, headers: [Accept:[application/json], Authorization:[Basic amVmZjpqZWZm], User-Agent:[Wink Client v1.1.2]]
2014-12-16 18:11:44,691 ERROR A backup could not be created. Reason: java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present
org.apache.wink.client.ClientRuntimeException: java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present
at org.apache.wink.client.internal.ResourceImpl.invoke(ResourceImpl.java:241) ~[wink-client-1.4.jar:1.4]
at org.apache.wink.client.internal.ResourceImpl.invoke(ResourceImpl.java:189) ~[wink-client-1.4.jar:1.4]
... 17 more frames available in the log file2) Bitbucket fails
The following appears in the atlassian-bitbucket.log while trying to create AppLinks:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2015-06-10 07:36:05,271 ERROR [http-nio-7990-exec-6] <USERNAME> @1MXVZCJx456x13355x0 18aal9q <YOUR_IP>,127.0.0.1 "GET /rest/applinks/2.0/applicationlinkForm/manifest.json HTTP/1.1" c.a.a.c.r.u.CreateApplicationLinkUIResource ManifestNotFoundException thrown while retrieving manifest
com.atlassian.applinks.spi.manifest.ManifestNotFoundException: javax.net.ssl.SSLException: java.security.cert.CertificateException: No subject alternative names present
at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.download1(AppLinksManifestDownloader.java:201) ~[applinks-plugin-4.3.7_1433795434000.jar:na]
at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.access$000(AppLinksManifestDownloader.java:44) ~[applinks-plugin-4.3.7_1433795434000.jar:na]
at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1$1.<init>(AppLinksManifestDownloader.java:86) ~[applinks-plugin-4.3.7_1433795434000.jar:na]
Caused by: javax.net.ssl.SSLException: java.security.cert.CertificateException: No subject alternative names present
...
at com.atlassian.sal.core.net.HttpClientRequest.executeAndReturn(HttpClientRequest.java:360) ~[sal-core-2.13.4.jar:na]
at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.download1(AppLinksManifestDownloader.java:150) ~[applinks-plugin-4.3.7_1433795434000.jar:na]
... 31 common frames omitted
Caused by: java.security.cert.CertificateException: No subject alternative names present
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:144) ~[na:1.8.0_45]
at sun.security.util.HostnameChecker.match(HostnameChecker.java:93) ~[na:1.8.0_45]
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.verifyHostName(SSLProtocolSocketFactory.java:284) ~[commons-httpclient-3.1-atlassian-2.jar:na]
... 43 common frames omittedCause
No subject alternative names present is caused when accessing an application over HTTPS by using the IP address on the URL rather than the domain contained in the remote SSL certificate and the SSL certificate being fetched does not contain the Subject Alternative Name (SAN) parameter with the matching IP address as an alternative attribute.Java is very strict about enforcing that the certificate contains a SAN entry for the IP address, if that is how it's being accessed.
This can also be caused by a bug in Java, see BSERV-7741 - Secure LDAP connections are broken when using Java 1.8u51+, 1.7.0_85+ and 1.6.0_101+ for more details.
Resolution
Commonly the certificate being fetched by Bitbucket Server or the backup client is self-signed can be loaded into 2 different locations:
Either directly into Bitbucket Server's Tomcat as described on Secure Bitbucket with Tomcat using SSL
Or in the Apache proxySecure Bitbucket with Apache using SSL
Therefore resolving this will require 2 different approaches.
If self-signed certificate your certificate is loaded on Tomcat
Generate the certificate on the remote application (could be loaded in Bitbucket Server, JIRA or Bamboo, for example) with a valid Subject Alternative Name entry for the IP address
If using a self-signed certificate, this can be done by adding the
-extflag to thekeytoolcommand1keytool -genkey -alias tomcat -keyalg RSA -ext san=ip:<IP_ADDRESS>
After generating the certificate with a valid SAN entry, Java may still not trust the certificate and throw a unable to find valid certification path to requested target error. In this cause, you'll need to manually import the certificate as described in Can't backup due to PKIX path building failed - unable to find valid certification path to requested target or [ARCHIVED] SSLHandshakeException - unable to find valid certification path to requested target.
If self-signed certificate your certificate is loaded on Apache
Configure the openssl.cnf file in the proxy machine with your IP YYY.YYY.YYY.YYY before creating the SSL certificate:
1. Search for [ req ] section inside the file and set the following line:
1
req_extensions = v3_req2. Then, search for [ v3_req ] section and add the following line:
1
subjectAltName = @alt_names3. Create the following lines at the bottom of the file:
1
2
[ alt_names ]
IP.1 = <YYY.YYY.YYY.YYY>4. Recreate the SSL certificate in this proxy server according to this Secure Bitbucket with Apache using SSL again
When creating the certificate,you might want to add the following parameter to the command to make sure the alternative names are really added
-extensions v3_req -extfile /etc/ssl/openssl.cnf
5. Set your proxy server to use the new SSL certificate
For more information, please refer to http://apetec.com/support/GenerateSAN-CSR.htm
After generating the certificate with a valid SAN entry, Java may still not trust the certificate and throw a unable to find valid certification path to requested target error. In this cause, you'll need to manually import the certificate as described in Can't backup due to PKIX path building failed - unable to find valid certification path to requested target or [ARCHIVED] SSLHandshakeException - unable to find valid certification path to requested target.
Optional:
This shouldn't be necessary, but while importing the certificate you might want to include this to the keytool command: -ext san=ip:<YYY.YYY.YYY.YYY>
Java version older than 1.8.0_65
If you are running a Java version older than 1.8.0_65, upgrade your Java version:
Java upgrade...
Upgrade Java to make sure that you are running at least version 1.8.0_65 (the bundled Java version has been upgraded as part of BSERV-8258 - Upgrade Bitbucket Embedded JRE to 1.8.0_65 from 1.8.0_60)
Was this helpful?