Uploaded image for project: 'Jira Server and Data Center'
  1. Jira Server and Data Center
  2. JRASERVER-65595

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



    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: High
    • Resolution: Fixed
    • Affects Version/s: 7.4.0, 7.2.8, 7.4.1, 7.4.2, 7.5.0, 7.4.3, 7.4.4, 7.4.5, 7.5.1, 7.5.2, 7.6.0, 7.5.3, 7.4.6, 7.5.4, 7.6.1, 7.7.0, 7.6.2, 7.6.3, 7.7.1
    • Fix Version/s: 7.6.4, 7.7.2, 7.8.0
    • Component/s: Application Links



      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).


      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, /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)


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


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


      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>



          Issue Links



              morzechowski Michal Orzechowski (Inactive)
              vdung Andy Nguyen (Inactive)
              20 Vote for this issue
              42 Start watching this issue