I need to automate server delivery with certificates; How can this be done?

Question

OS: CENTOS-7

As a system admin, reducing maintenance by having a repeatable delivery is immensely valuable; So if I need to redeliver the server for whatever reason, I can do so with no modification to end data, and no prep/alterations of the server, just run the script and the server will be running with the previous data.

Because much of the configuration of the server itself is maintained in its' home directory much of the delivery is looked after with the installation, but I am unsure of how to automate the installation of the certificate which will be used to validate the front-end proxy's certificate.

This will require knowing where the configuration for the following are;

The keystore which jira uses,

The certificate password.

Once I have a way to modify these I can deliver this server in a quick minute from nuts+bolts infrastructure.

admin admin_trokdm · Answer

Hi Daniel,

The issue as I understand it is that I developed my Docker containers in Alpine, so I don't believe they had the certificate chains by default, so the container would not inherently trust LetsEncrypt, thus every certificate change we implemented resulted in needing to re-install the certificate into the local trust store.

I am redelivering my servers using CentOS, so I am tentatively hopeful that this will not be necessary any longer, provided I can set up a chain-of-trust to the LetsEncrypt root certificate.

Daniel Eads · Answer

Hey Shane,

Just wanted to follow up and make sure you have everything you need on this question.

By default, Jira uses the standard keystore in the JRE it's running under:
$JAVA_HOME/jre/lib/security/cacerts

If your reverse proxy is configured with a certificate signed by a standard Certificate Authority (not self-signed or an internal CA), you probably should be good to go! GoDaddy famously was circulating certificates that were not trusted by Java 7, but nearly anything you can get these days (including Let'sEncrypt) should be trusted in Java 8 and above.

If your certificate isn't trusted for some reason, follow the instructions in our How to import a public SSL certificate into a JVM document. The commands are going to be fairly similar to what you've listed already - first fetching the certificate from your reverse proxy and then importing it using the keytool utility.

The only caveat you'll need to consider is that the $JAVA_HOME is going to be the system-wide JRE if you installed Jira with the .tar.gz archive, which doesn't bundle a JRE. By default, the .bin installer uses its own bundled JRE. From your previous questions, I think you're currently working against a .tar.gz install, which depends on the JRE you've installed at a system level.

Cheers,
Daniel | Atlassian Support

admin admin_trokdm · Answer

Hi Shankar,

Thanks for your feedback.  I found tomcat quite a hassle a few years ago and moved my infrastructure to a reverse-proxy which front-ends all of the certificates necessary;

What I am looking for isn't related to providing SSL.  I need to know what Jira uses to trust other servers and itself; validating the ssl certificate.

Jira server for instance, because it uses its own APIs, requires the capability to trust our reverse proxy placed in front of the server.  To allow this, I need to know which trust store to install the proxy's certificate into.  In a previous docker server I developed for instance, I needed to run this;

openssl s_client -connect "${APP_URL}":443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/public.crt && cd /usr/lib/jvm/java-8-oracle/bin && keytool -import -noprompt -alias "${APP_URL}" -keystore ${JKS} -storepass ${JKS_PW} -file /tmp/public.crt && rm /tmp/public.crt

This implies that Jira uses the trust store attributed to the Java platform it is configured to use;
https://confluence.atlassian.com/crowd/setting-java_home-61604243.html
In my case this will be done by loading an environment variable to the operating user as below;
JAVA_HOME=/dir/java_home