Hi Roshan,
Yes.
The problem is that 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 truststore. This contains a list of all the known CA certificates and Java will only trust certificates that are signed by those CA certificate or public certificates that exist within that keystore.
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 Certification Authority. Those three certificates combined are referred to as the certificate chain. As all of those CA certificates are within the Java truststore (cacerts), Java will trust any certificates signed by them (in this case, *.atlassian.com). Alternatively, if the *.atlassian.com certificate was in the truststore, Java would also trust that site.
This problem comes from a certificate that is either self-signed (meaning a CA did not sign it), the certificate chain does not exist within the Java truststore or the server is not serving the intermediate certificates. Subsequently, JIRA doesn't trust the certificate and fails to connect to the application
For workaround you can have a look in this documentation:
https://confluence.atlassian.com/display/JIRAKB/Unable+to+Connect+to+SSL+Services+due+to+PKIX+Path+Building+Failed+sun.security.provider.certpath.SunCertPathBuilderException
Cheers,
WZ
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.