Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

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

admin admin
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 24, 2019

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.

1 answer

0 votes
Shankar Asam {Appfire}
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 26, 2019

Hi Shane,

To answer your question on Keystore;

If your site's SSL certs are loaded into JIRA(tomcat), then you can find those certs in

1) server.xml (inside your jira install directory) - check the locations of keystore file below;

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
              maxHttpHeaderSize="8192" SSLEnabled="true"
              maxThreads="150" minSpareThreads="25"
              enableLookups="false" disableUploadTimeout="true"
              acceptCount="100" scheme="https" secure="true"
              sslEnabledProtocols="TLSv1.2,TLSv1.3"
              clientAuth="false" useBodyEncodingForURI="true"
              keyAlias="jira" keystoreFile="<JIRA_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

2) Java will normally use a system-wide keystore in $JAVA_HOME/jre/lib/security/cacerts - you can also check the certs by using keytool command on $JAVA_HOME/jre/lib/security/cacerts file. keytool to view the certs.

 

If hosting JIRA behind a reverse-proxy, such as Apache, please see check the SSL certs in your apache server and its configuration. Here is the KB article on that.

-Shankar

admin admin
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 31, 2019

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

Daniel Eads
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 31, 2019

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 16, 2019

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.

Suggest an answer

Log in or Sign up to answer