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:
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG