Gadget titles incorrect with SSLPeerUnverifiedException errors in logs in Jira server
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
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
The following stack trace could be found in atlassian-jira.log and usually associated with the gadget is having a problem showing the titles as in Fix gadget titles showing as __MSG_gadget in Jira server article:
2017-11-08 15:35:16,648 https-jsse-nio-8443-exec-1 ERROR admin 935x459x1 v4sd44 127.0.0.1 /rest/config/1.0/directoryitems/local.json [c.a.g.r.internal.http.HttpClientFetcher] Unable to perform a request to: https://julian.jdc.com:8443/rest/gadgets/1.0/g/messagebundle/en_US/gadget.common%2Cgadget.voted%2Cgadget.issuetable.common
javax.net.ssl.SSLPeerUnverifiedException: Certificate for <julian.jdc.com> doesn't match any of the subject alternative names: [www.abc.com]
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:467)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
at com.atlassian.gadgets.renderer.internal.http.HttpClientFetcher.fetch(HttpClientFetcher.java:87)
at org.apache.shindig.gadgets.DefaultMessageBundleFactory.fetchBundle(DefaultMessageBundleFactory.java:138)
at org.apache.shindig.gadgets.DefaultMessageBundleFactory.getNestedBundle(DefaultMessageBundleFactory.java:111)
at org.apache.shindig.gadgets.DefaultMessageBundleFactory.getBundle(DefaultMessageBundleFactory.java:79)
at org.apache.shindig.gadgets.variables.VariableSubstituter.substitute(VariableSubstituter.java:47)
at com.atlassian.gadgets.renderer.internal.GadgetSpecFactoryImpl.getGadgetSpec(GadgetSpecFactoryImpl.java:127)
at com.atlassian.gadgets.renderer.internal.GadgetSpecFactoryImpl.getGadgetSpec(GadgetSpecFactoryImpl.java:83)
... 2 filtered
...Diagnosis
Environment
- JIRA is running over SSL/HTTPS
- Certificate has been duly imported into Java's truststrore. See Connecting to SSL services
Diagnostic Steps
- Run the following command to get the details of the Certificate:
<JAVA_HOME>/bin/keytool -list -v -alias <server_name> -keystore <JAVA_HOME>/jre/lib/security/cacertsThe expected result for the command above is that the SAN Entries to include the CN as well like below where CN=julian.jdc.com also in SAN DNSName=julian.jdc.com
Alias name: julian.jdc.com
Creation date: Nov 8, 2017
Entry type: trustedCertEntry
Owner: CN=julian.jdc.com, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Issuer: CN=julian.jdc.com, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Serial number: 2f31ba8a
Valid from: Wed Nov 08 15:40:51 MYT 2017 until: Tue Feb 06 15:40:51 MYT 2018
Certificate fingerprints:
MD5: 4A:B9:F7:CC:4D:7A:CC:D3:88:4C:58:46:CE:B2:97:C8
SHA1: A8:EE:23:A3:6C:D6:BB:FD:49:C2:04:EC:BE:D6:6B:39:FE:36:FA:AD
SHA256: 7A:3C:4C:72:8D:6B:10:5C:F3:20:5A:61:E7:C4:84:A9:9E:E6:C1:C5:2F:24:33:14:F5:10:3E:30:05:1C:E3:EA
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: www.abc.com
DNSName: julian.jdc.com
]
#2: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 21 80 8A EE AC 51 89 59 3B 7D 74 14 AA AF 6A AD !....Q.Y;.t...j.
0010: 0F BC 68 25 ..h%
]
]Cause
Taken from RFC 2818 (the HTTPS specification), it is required to include every Hostname in the SAN Entries including the Common Name(CN):
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
Resolution
Generate another certificate where the SubjectAlternativeName(SAN) include JIRA Hostname or the CN.