JIRA applinks fail if SSL certificate uses Subject Alternative Name (SAN)

Summary

Attempting to create an application link from JIRA to another application will fail if that application runs over HTTPS with an SSL certificate that uses Subject Alternative Name (SAN). This will also impact existing Application Links, causing them to stop working. This will also impact JIRA gadgets in case of JIRA is behind the proxy with TLS offload as JIRA needs to connect to itself through proxy (see JRASERVER-64137).

Environment

JIRA 7.4.0 bundled with Apache HttpClient 4.5.3.

Steps to reproduce

1. Configure JIRA and Bamboo to run over HTTPS with an SSL certificate using SAN
2. Ensure Bamboo's certificate has been imported into JIRA's trust store (and vice-versa)
3. From JIRA, create an application link to Bamboo

Expected behavior

• The applinks creation is successful on both sides.
• JIRA is able to load gadgets

Actual behaviour

The applinks fails on JIRA side with the following symptoms:

• Bamboo is not detected and JIRA is asked to provide Consumer key and Shared secret as if Bamboo's SSL cert hadn't been imported. However, there's no PKIX error in the log.
• Upon the creation completion (just Continue), the following error appears in JIRA GUI:
  
• In JIRA log, the following error is thrown:

  2017-07-04 03:54:55,130 https-jsse-nio-8444-exec-11 ERROR username 234x15407x1 fdav2p 109.150.52.183,10.101.200.31 /rest/applinks/3.0/applinks [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: java.lang.ClassCastException: [B cannot be cast to java.lang.String
  com.google.common.util.concurrent.UncheckedExecutionException: java.lang.ClassCastException: [B cannot be cast to java.lang.String
  	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
  	at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
  	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
  ...
  Caused by: java.lang.ClassCastException: [B cannot be cast to java.lang.String
  	at org.apache.http.conn.ssl.DefaultHostnameVerifier.getSubjectAltNames(DefaultHostnameVerifier.java:309)
  	at org.apache.http.conn.ssl.DefaultHostnameVerifier.verify(DefaultHostnameVerifier.java:112)
  	at org.apache.http.conn.ssl.DefaultHostnameVerifier.verify(DefaultHostnameVerifier.java:99)
  	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:463)
  ...

Cause

JIRA 7.4 uses Apache HttpClient 4.5.3 as can be seen in pom.xml:

<apache.httpclient.version>4.5.3</apache.httpclient.version>

This version carries this bug that affects SSL certificates with SAN:

• https://issues.apache.org/jira/browse/HTTPCLIENT-1836

Workarounds

1. Use unproxied applinks that would bypass the SSL check
   • Temporarily use the linked application/s over HTTP (Bamboo as in the context of this report)
2. Temporarily use a certificate that doesn't use SAN
   • This could be a problem if you use Chrome 58+

Note on fix

httpclient version was upgraded to 4.5.4: pom.xml

-        <apache.httpclient.version>4.5.3</apache.httpclient.version>
+        <apache.httpclient.version>4.5.4</apache.httpclient.version>

Note

• This may cause a JIRA's Base URL healthcheck problem which in turn leads to the following problem:
  • Error when logging in or visiting dashboards
• Also note that Chromium/Chrome removed support for matching common name (CN) in certificates in M58, so enforcing users to switch to SAN, so that makes bug more critical.
  • https://bugs.chromium.org/p/chromium/issues/detail?id=308330