Resolve Cloud Applinks and SSL errors
Platform Notice: Cloud and Data Center - This article applies equally to both cloud 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
Summary
Symptoms
Attempting to access encrypted URLs with SSL (for example, HTTPS, LDAPS, IMAPS) throws an exception, and Jira refuses to connect.
For example, the following may appear in the logs (which are only accessible to Atlassian Support engineers):
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
at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:441)
at javax.mail.Service.connect(Service.java:233)
at javax.mail.Service.connect(Service.java:134)Another thing you might come across is the famous screen similar to:
This is the same as the error generated in the browser when visiting a page encrypted with a self-signed certificate, except Java can't proceed anyway; it just refuses the certificate. This is because of how Java works, not your browser.
Diagnosis
You will need an SSL. If you don't have one yet, follow the steps to obtain one from a Certificate Authority.
Certificate authority certificate
Digital Certificates issued by trusted 3rd party Certification Authorities (CAs) verify your website's identity. Many CAs verify the domain name and issue the certificate. Other CAs, such as Comodo, also verify your business's existence, your domain name's ownership, and the authority to whom the certificate application was made, thereby providing a higher standard of identification and authenticity.
Let's make sure you have the correct requirements setup:
All applications
The on-premise application you want to link to your cloud site must be accessible via the supported ports: 80, 443, 8080, 8443, 8444, 7990, 8090, 8085, 8060, 8900, 9900
If you want to use SSL, you must use a valid certificate (not a self-signed certificate). See Java documentation for more information.
Also, use this link to make sure your SSL is configured correctly.
Cause
Whenever Jira attempts to connect to another application over SSL (for example, HTTPS, IMAPS, LDAPS), it can only connect to that application if it can trust it. The way trust is handled in the Java world (this is what Jira is written in) is that you have a Keystore (typically$JAVA_HOME/lib/security/cacerts. Java), also known as the trust store. This contains a list of all the known CA certificates, and Java will only trust certificates signed by those CA certificates or public certificates that exist within that Keystore.
Let's take a look at an example, the certificate for Atlassian:
We can see the intermediate certificates, DigiCert High Assurance EV Root CA and DigiCert High Assurance CA-3, have signed the *.atlassian.com certificate. These intermediate certificates have been signed by the root Entrust.net Secure server CA. Those three certificates combined are referred to as the certificate chain. As all of those CA certificates are within the Java Keystore (cacerts), Java will trust any certificates signed by them (in this case, *.atlassian.com). Alternatively, Java would also trust that site if the *.atlassian.com certificate was in the Keystore.
This problem comes from a certificate that is either self-signed (a CA did not sign it) or the certificate chain does not exist within the Java Keystore. Subsequently, Jira doesn't trust the certificate and fails to connect to the application.
Solution
Now that you have your certificates and are ready to wrap everything up, let's ensure your SSL works after being installed. Remember to use the SSL checker above.
If you still have issues, work with your Certificate Authority provider to ensure the SSL Certs are correct.
All applications
The on-premise application you want to link to your Cloud site must be accessible via the supported ports: 80, 443, 8080, 8443, 8444, 7990, 8090, 8085, 8060, 8900, 9900.
If you want to use SSL, you must use a valid certificate (not a self-signed certificate). The list of supported CAs can be found in Oracle's Java documentation.
Also, use this link to make sure your SSL is configured correctly.
You can use SSLpoke to debug. It simply connects to an SSL service, sends a byte of input, and watches the output. For instance, connecting to a local HTTPS server on port 443 (the HTTPS default) with an untrusted (self-signed) certificate:
|
And connecting to a CA-verified certificate:
|
Here we see a successful connection:
|
If this fails (confirming the issue), the solution is to remove the -Djavax.net.ssl.trustStore parameter, import the custom Keystore certificates into the main Keystore with keytool -importkeystore -srckeystore /my/custom/keystore -destkeystore $JAVA_HOME/jre/lib/security/cacerts, and restart the application.
If the certificate is trusted and found by Java, and there are low-level SSL problems, debug information can be obtained in the stdout logs by setting the -Djavax.net.debug=all property.
If you are still having issues it may be necessary to restart the service.
Was this helpful?