How to add SSL certificates to standalone atlassian products like jira and confluence in such way they are preserved on upgrades?

[Sorin Sbarnea (Citrix)]

How to add SSL certificates to standalone atlassian products like jira and confluence in such way they are preserved on upgrades?

Atlassian standalone products do include their own Java distribution and I was unpleasantly surprised to discover that on product upgrades the certificates are lost, because they are part of the JRE.

What is the proper way to add these certificates that will assure that they are preserved on upgrades, and preferably even if we move the installation to another machine?

[RianA]

Hi Sorin,

In order to preserve the certificate, I would suggest you to change the way of upgrade. We intend to provide less hassle upgrade to those less technical people with our installer. However for technical administrator like you we would suggest you to upgrade the system manually, so that the installer will be pointed to the JAVA_HOME and its keystore. That way, you would be able to preserve the keystore of the application.

Cheers,
Josua

[Sorin Sbarnea (Citrix)]

Thanks Rian. I like the idea of the installer and I think that you should include this use case in the installer or document a way of adding the key that will not be lost after an upgrade.

The keys could be stored in an additional keystore and configure JVM to use this store. Still, this would require the installer to keep this customization which, if I am not wrong should be inside setenv.sh file.

[MattS]

One problem is that it is not documented where the the JAVA_HOME variable is set by the JIRA Linux installer. I believe that it is bin/permgen.sh

The answer for Confluence is not documented on the manual upgrade page but appears to be "add it to the top of bin/setenv.sh"

[Dave C]

Best bet here is to host your own cacerts trust store outside of the JAVA_HOME and tell the JVM to use that - for example:

1. Copy the JAVA_HOME/lib/security/cacerts to JIRA_HOME/cacerts
2. Specify the following JVM arguments:

• -Djavax.net.ssl.trustStore=JIRA_HOME/cacerts and
• -Djavax.net.ssl.keyStorePassword=changeit

Then when you upgrade JIRA, as long as you ensure those JVM arguments are copied across it will continue to use that trust store. This means you don't have to mess around with manual installations of JIRA, can continue to use the bundled installer and also don't have to go changing around the Java version.

Also with these certificates, are you using self-signed certs or CA-signed certs? If they're CA-signed certs and you still need to add the public cert into the keystore it's likely the web server may not be serving the intermediate certificates, which are used to establish the trust chain to the root. For example:

public cert -> intermediate(s) -> root (ca) cert

If those intermediate(s) are not served Java won't be able to trust the cert - a workaround is to import the public cert, however it addresses the symptom instead of the root cause. If you ensure the web server is providing that intermediate(s) cert(s) Java can establish trust. On the other hand if you're using self-signed there isn't a lot that can be done here other than import them or sign them with a self-signed CA and import that.