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.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.