JIRA Does Not Start after Configuring SSL Due to Unspecified TrustStore or Keystore Path
Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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
Symptoms
After performing all steps from JIRA running over SSL, startup results in a message saying that it is unable to find valid certification path to request target (shown in the logs). It is important to note that you already edited the server.xml as required, imported the certificate to the keystore and manually added this path to your server.xml. Notwithstanding, the error persists.
Trusted Application
This same issue may occur when setting trusted application.
The following appears in the atlassian-jira.log:
2011-02-25 17:27:01,062 http-8443-6 WARN admin 1047x177x1 19yxz8q 127.0.0.1 /secure/admin/trustedapps/ViewTrustedApplications!request.jspa [action.admin.trustedapps.ViewTrustedApplications] com.atlassian.security.auth.trustedapps.ApplicationRetriever$RemoteSystemNotFoundException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
com.atlassian.security.auth.trustedapps.ApplicationRetriever$RemoteSystemNotFoundException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Cause
The JRE has two different stores:TrustStore(certificates of authority) andKeyStore(JRE-specific certificates that will be presented to browsers, et cetera). The $JAVA_HOME environment variable usually corresponds to the path of these certificates,since the JRE (and server.xml) usually looks inside the %JAVA_HOME%/jre/lib/security/cacerts.
However, on Windows systems and in some special circumstances where the 'keytool' command is used by various accounts in the operating system, a (hidden) keystore file is generated in the user's home directory which usually goes unnoticed even though this is where imported certificates are being stored.
Resolution
Add to your JAVA_OPTS parameter as the following:
-Djavax.net.ssl.trustStore=$TRUSTSTORE" (which $TRUSTSTORE relates to the location where the cacerts file resides)
-Djavax.net.ssl.trustStorePassword=changeit" (or whatever password was specified if using a custom cacerts)
-Djavax.net.ssl.keyStore=$KEYSTORE" (the path of keystore, whether it's the default cacerts file or a separate keystore file)
-Djavax.net.ssl.keyStorePassword=changeit" (or whatever password was specified if using a custom keystore file)
Restart your instance.
Was this helpful?