No Subject Alternative Names

Troubleshooting Backup Client

On this page

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community

Symptoms

Your Stash backup client or Stash 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):

$ java -jar stash-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 file

2) Stash fails

The following appears in the atlassian-stash.log while trying to create AppLinks:

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 omitted

Cause

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.

Resolution

Commonly the certificate being fetched by Stash or the backup client is self-signed can be loaded into 2 different locations:

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 Stash, 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 -ext flag to the keytool command

    keytool -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 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:

req_extensions = v3_req


2. Then, search for [ v3_req ] section and add the following line:

subjectAltName = @alt_names

 

3. Create the following lines at the bottom of the file:

[ alt_names ]
IP.1 = <YYY.YYY.YYY.YYY>


4. Recreate the SSL certificate in this proxy server according to this Securing Stash 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 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>

Last modified on Mar 30, 2016

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.