SSL connections fail from Jira Data Center to external systems
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles 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
- When sending a test email via an SSL connection, mail will not be sent
- Jira applications cannot access the Universal Plugin Manager (UPM) to install or upgrade plugins
The following appears in the atlassian-jira.log:
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at com.sun.jersey.client.apache.ApacheHttpClientHandler.handle(ApacheHttpClientHandler.java:202)
at com.sun.jersey.api.client.Client.handle(Client.java:365)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:556)
at com.sun.jersey.api.client.WebResource.get(WebResource.java:178)
at com.atlassian.plugins.client.service.product.ProductServiceClientImpl.getProductVersionsAfterVersion(ProductServiceClientImpl.java:82)
at com.atlassian.upm.pac.PacClientImpl.getProductUpgrades(PacClientImpl.java:111)
at com.atlassian.upm.rest.resources.ProductUpgradesResource.get(ProductUpgradesResource.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper$ResponseOutInvoker$1.invoke(DispatchProviderHelper.java:206)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper$1.intercept(DispatchProviderHelper.java:90)
at com.atlassian.plugins.rest.common.interceptor.impl.DefaultMethodInvocation.invoke(DefaultMethodInvocation.java:61)
at com.atlassian.plugins.rest.common.expand.interceptor.ExpandInterceptor.intercept(ExpandInterceptor.java:38)
at com.atlassian.plugins.rest.common.interceptor.impl.DefaultMethodInvocation.invoke(DefaultMethodInvocation.java:61)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper.invokeMethodWithInterceptors(DispatchProviderHelper.java:98)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper.access$100(DispatchProviderHelper.java:28)
at com.atlassian.plugins.rest.common.interceptor.impl.DispatchProviderHelper$ResponseOutInvoker._dispatch(DispatchProviderHelper.java:202)
...
Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
...
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
...
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
Cause
The JVM cannot find the javax.net.ssl.trustStore required for SSL, it does not contain the required certificates, or it isn't in the expected format.
For standard installations, we do not recommend this JVM argument is used, and rather your certificates are added to the JVM's default keystore, which is typically located in $JAVA_HOME/jre/lib/security/cacerts or the keystore used by your Tomcat, as in our Running JIRA over SSL or HTTPS documentation.
In that case, make sure the user running the Jira process has the proper permissions to access the cacerts file.
Resolution
Follow our Connecting to SSL services documentation. This will guide you through obtaining the certificate of the service you're accessing and importing it into the recommended Java keystore. Additionally, verify the current keystore type:
<JAVA_HOME>/bin/keytool -list -keystore <JAVA_HOME>/lib/security/cacerts>If the output confirms the keystore is PKCS, then we must convert it to JKS. After all steps are complete, you'll need to restart Jira for changes to take effect:
keytool -importkeystore -srckeystore cacerts -destkeystore cacertsJKS -deststoretype JKSThen, rename initial cacerts to cacertsPKCS and cacertsJKS to cacerts.
If you're using a non-standard keystore, such as the one specified in Tomcat, please import the certificate into that keystore.