Are Thawte Domain Validated Certificates Trusted in JIRA Cloud for Application Links?

[James Alexander]

I am attempting to create an application link between our JIRA Cloud instance, and a Crucible "Server" install I have made on an EC2 instance. I'm running crucible behind an NGINX reverse proxy. Initially, to test the configuration, I served our crucible instance purely on HTTP over port 80. The application link worked without issue between JIRA Cloud and our Crucible instance. However, whenever I turned on the SSL in NGINX, I received the following error while attempting to create the link:

No response was received from the URL you entered - it may not be valid. Please fix the URL below, if needed, and click Continue.

Since I didn't see any access entries hitting my NGINX logs, I assumed there was a problem with the SSL handshake. I extracted the following from the ssldump command:

New TCP connection #1: squid-104-1.sc1.uc-inf.net(49050) <-> ip-172-31-37-162.ec2.internal(443)
1 1  0.0749 (0.0749)  C>SV3.1(191)  Handshake
      ClientHello
        Version 3.1 
        random[32]=
          54 f9 a5 fa cf f0 5d 5f ff 49 78 ef c4 b1 03 ae 
          d9 98 69 37 ea 02 83 91 82 26 f9 9c 97 7c 32 56 
        cipher suites
        Unknown value 0xc009
        Unknown value 0xc013
        TLS_RSA_WITH_AES_128_CBC_SHA
        Unknown value 0xc004
        Unknown value 0xc00e
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        Unknown value 0xc007
        Unknown value 0xc011
        TLS_RSA_WITH_RC4_128_SHA
        Unknown value 0xc002
        Unknown value 0xc00c
        Unknown value 0xc008
        Unknown value 0xc012
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        Unknown value 0xc003
        Unknown value 0xc00d
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_RC4_128_MD5
        Unknown value 0xff
        compression methods
                  NULL
1 2  0.0767 (0.0017)  S>CV3.1(89)  Handshake
      ServerHello
        Version 3.1 
        random[32]=
          4f 0f 5b 13 61 27 48 81 2e 87 22 dd 5c ab 47 8a 
          89 e8 a3 65 2d 3f ae a1 93 98 d0 60 19 5f e8 f2 
        session_id[32]=
          23 14 70 8f ff 7f 74 d0 ac da 85 71 9f 09 9f 8d 
          79 fe 9e b0 bd 24 a8 95 d6 d2 1c dd dc 2c d4 e6 
        cipherSuite         Unknown value 0xc013
        compressionMethod                   NULL
1 3  0.0767 (0.0000)  S>CV3.1(1200)  Handshake
      Certificate
        certificate[1190]=
    # -- certificate truncated -- #
1 4  0.0767 (0.0000)  S>CV3.1(331)  Handshake
      ServerKeyExchange
1 5  0.0767 (0.0000)  S>CV3.1(4)  Handshake
      ServerHelloDone
1 6  0.1606 (0.0838)  C>SV3.1(2)  Alert
    level           fatal
    value           certificate_unknown
1    0.1607 (0.0001)  C>S  TCP FIN
1    0.1608 (0.0000)  S>C  TCP FIN
New TCP connection #2: squid-104-1.sc1.uc-inf.net(52238) <-> ip-172-31-37-162.ec2.internal(443)
2 1  0.0695 (0.0695)  C>SV3.0(191)  Handshake
      ClientHello
        Version 3.0 
        random[32]=
          54 f9 a5 fa 47 04 5e 59 c7 74 d2 3a e3 b9 da a1 
          51 94 e4 bc 22 c0 45 16 9e 85 de 56 7a 7d 9e 18 
        cipher suites
        Unknown value 0xc009
        Unknown value 0xc013
        SSL_RSA_WITH_AES_128_CBC_SHA
        Unknown value 0xc004
        Unknown value 0xc00e
        SSL_DHE_RSA_WITH_AES_128_CBC_SHA
        SSL_DHE_DSS_WITH_AES_128_CBC_SHA
        Unknown value 0xc007
        Unknown value 0xc011
        SSL_RSA_WITH_RC4_128_SHA
        Unknown value 0xc002
        Unknown value 0xc00c
        Unknown value 0xc008
        Unknown value 0xc012
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        Unknown value 0xc003
        Unknown value 0xc00d
        SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_RC4_128_MD5
        Unknown value 0xff
        compression methods
                  NULL
2 2  0.0712 (0.0017)  S>CV3.0(89)  Handshake
      ServerHello
        Version 3.0 
        random[32]=
          7b 4d f4 ad a0 9c 3c 88 8a 29 00 9d 5f ad 51 5d 
          26 a9 14 9c cc 4b 25 44 9e b5 16 89 b3 75 3e d0 
        session_id[32]=
          05 57 c3 f9 59 f8 67 2a 96 38 ad 59 06 7a 4a 9e 
          59 33 48 01 cd 2d b1 d0 0c c3 6d 66 2f 46 5f 6c 
        cipherSuite         Unknown value 0xc013
        compressionMethod                   NULL
2 3  0.0712 (0.0000)  S>CV3.0(1200)  Handshake
      Certificate
        certificate[1190]=
    # -- certificate truncated -- #
2 4  0.0712 (0.0000)  S>CV3.0(331)  Handshake
      ServerKeyExchange
2 5  0.0712 (0.0000)  S>CV3.0(4)  Handshake
      ServerHelloDone
2 6  0.1466 (0.0754)  C>SV3.0(2)  Alert
    level           fatal
    value           certificate_unknown
2    0.1466 (0.0000)  C>S  TCP FIN
2    0.1467 (0.0000)  S>C  TCP FIN

The error toward the end of each connection attempt: "Alert, level: fatal, value: certificate_unknown" leads me to believe there is a problem with our certificate. However, when I connect to https://support.leafsoftwaresolutions.com, the certificate is valid according to Firefox and Chrome.

Is there any reason why our certificate would not be trusted by the JIRA Cloud instance while attempting to create the application link?

[James Alexander · Accepted solution]

For future reference, I was able to figure out my own issue. 

I noticed that not only did JIRA not authenticate, but FireFox also did not automatically trust my SSL certificate. The issue for me was in how I had installed the certificate. I was exporting the cert from a windows server that was previously hosting the same domain. When I exported the certificate from the windows certificate manager, I failed to check the "Include all certificates in the certification path if possible" check box, and thus lead me to this issue. 

See this page for the full instructions to export your certificate from windows to make it ready to host on an NGINX server on Ubuntu.