Cloud Applinks and SSL

Still need help?

The Atlassian Community is here for you.

Ask the community

Symptoms

Attempting to access URLs that are encrypted with SSL (for example HTTPS, LDAPS, IMAPS) throws an exception and JIRA refuses to connect to it.

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 following error that's generated in browser when visiting a page that's encrypted with a self-signed certificate, except Java can't " Proceed anyway ", it just refuses the certificate. This is because of how Java works and not your browser.

Diagnosis

You will need to have your SSL; If you do not have one yet follow how to obtain an SSL certificate from a Certificate Authority.

Certificate authority certificate

Digital Certificates issued by trusted 3rd party Certification Authorities (CAs) provide verification of the identity of your website. Many CAs simply verify the domain name and issue the certificate. Other CAs such as  Comodo also verify the existence of your business, the ownership of your domain name, 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. The list of the supported CA can be found HERE)

Also, use this link to make sure your SSL is configured correctly.

Cause

Whenever JIRA attempts to connect to another application over SSL (e.g.: HTTPS, IMAPS, LDAPS), it will  only be able to 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 ) or also known as the trust store. This contains a list of all the known CA certificates and Java will only trust certificates that are 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 *.atlassian.com certificate has been signed by the intermediate certificates, DigiCert High Assurance EV Root CA and DigiCert High Assurance CA-3. 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, if the *.atlassian.com certificate was in the Keystore, Java would also trust that site.

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.

Resolution

  • Now that you have your Certs and are ready to wrap everything up. Let's make sure that your SSL is good now that it's installed. Remember to use the SSL checker above.
  • If you are still having issues work with your Certificate Authority provider to make sure 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 the supported CA can be found HERE)

    Also, use this link to make sure your SSL is configured correctly.

SSLPoke

The attached SSLPoke.class Java program (source) is useful for debugging. 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:


USERNAME:~$ java SSLPoke localhost 443
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to  find valid certification path to requested target
         at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:285)
         at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:191)
        ...
         at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:73)
         at SSLPoke.main(SSLPoke.java:28)
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to  find valid certification path to requested target
         at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174)
         at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
         at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280)
         ... 15  more


And connecting to a CA-verified certificate:


USERNAME:~$ java SSLPoke mail.atlassian.com 443
Successfully connected

Here we see a successful connection


java -Djavax.net.ssl.trustStore= /my/custom/keystore SSLPoke localhost 443


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.

Last modified on Mar 21, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.