Certificates with JIRA

[rstevens79]

ENVIRONMENT:

1. OS = CentOS 7 Minimal v1806, fully updated
2. JIRA Software 8.4.1
3. Open Source CA (on-premise)

We have installed the base OS, CentOS 7. Our CA is on-premise, and we are the admins. We have generated a PEM Key Pair for use on the server and with JIRA. The full generated certificate includes the KEY, the Signed CERT, and the CHAIN. We break these apart into KEY.PEM, CERT.PEM, and CHAIN.PEM. Each are installed on the server for their respective use for various uses on the server, not just JIRA. The goal is to use the existing generated certificates with JIRA as well

After installing JIRA, we followed the instructions to create the JKS Keystore. This is done in JKS format.

ASSUME THE FOLLOWING:

1. The Server.xml file was configured with the proper HTTPS connector for port 8443
2. The firewall has port 8443 open (as well as 80/443/8080/5432
3. The CA certs were installed into the JAVA_HOME cacerts keystore
4. The KEY.PEM begins with -----BEGIN PRIVATE KEY..... and ends with ....END PRIVATE KEY------ Headers have been stripped out
5. The Signed Cert begins with -----BEGIN CERTIFICATE..... and ends with .....END CERTIFICATE----- Headers have been stripped out
6. We are not CA/PKI experts (haha!)

ATTEMPTS:

1. Used keytool to try import the KEY.PEM into the Keystore - RESULT: Cannot import the KEY.PEM into the keystore
2. Combined and converted the KEY.PEM and CERT.PEM into a P12 using openssl. Converted the JKS Keystore into a PKCS12 format. Used keytool to import the combined P12 into the Keystore. RESULT: This is successful in that the P12 imports into the Keystore. The HTTPS connector type was changed from JKS to PKCS12, but after restarting the server the page loads with the self-signed certificate. It loads just fine for HTTP. Looking at the contents of the JKS Keystore and it only shows the imported Cert, so not even sure where it's pulling the self-signed cert from
3. Instead of generating a PEM Key Pair from the CA, we generated a P12 Key Pair directly from the CA. We did NOT break it apart into KEY/CERT/CHAIN. Used keytool to import the P12 Keystore into the JKS Keystore. RESULT: It imported fine, but the Page fails to load after a server restart. Tried setting the Connector to JKS and PKCS12 respectively, but neither made a difference
4. Converted the KEY.PEM to DER format (pkcs8) RESULT: The key imports fine into the JKS Keystore, but cannot import the Signed Cert PEM into the Keystore

Here is the only way we can get it to work:

1. Create a JKS Keystore
2. Generate a CSR using keytool
3. Submit the CSR to our CA, and sign it receiving a Cert that includes the Signed Cert and the CA CHAIN
4. The above Signed Cert includes Headers (Subject: CN=.......Issuer: C=.....). We did not modify this at all
5. Used keytool to import the Cert into the Keystore
6. Modified the Connector for HTTPS/8443 pointing to this Keystore with JKS type
7. Used keytool to import the CA Certs into the JAVA_HOME cacerts Keystore
8. Reboot the Server
9. The web page is accessible properly with the correct Cert and is trusted

CONCLUSION: The only way we can get this work is to use the CSR method. Without going into more detail than I already have (if you made it this far), this is not preferred. The Certs are created and installed on the Server long before JIRA (or any application) is installed on the server, and we'd like to keep this process if possible. I'm sure this is just a matter of figuring the proper way to convert the Cert into a format that the JKS will accept, but it's a little bit out of our expertise now. Anyone have any ideas on what we can do to use the original KEY.PEM, CERT.PEM, CHAIN.PEM with JIRA?

[Andrew Laden · Accepted solution]

A common solution is to not have jira handle the ssl encryption itself, but front it with nginx or apache, which handles the ssl, and then proxies to jira. This may give you more options for how to handle the certs in nginx, which can use the pem and key files.

It also has the side benefit of offloading the ssl work to a different process, which has some performance benefits.

To enforce, you can firewall the ports so that only localhost connections can connect to the jira port.

[rstevens79]

@Andrew Laden Thank you for the response. We had considered that, and saw that as a possible option as well. While that is a technical possibility and something we may end up doing, I need to revise my original question a bit. We are trying to figure out how to do this directly on the JIRA server itself. I will still accept your answer as a solution as technically it is a solution.

The original goal is to use our Internal CA issued certs without having go through the CSR method - and do this on the server itself. We have full control of the CA, so if there's a format that the certs need to be issued in, etc, we can accommodate that.

In the end, the answer simply may be "it's not possible" or "that's not the recommended", but just wanted to reach out to the community to see if anyone else has been able to do this with existing issued certs without having to go through the CSR method.

[Andrew Laden]

Well I hate leaving this open, So I Dug a little. You don't want to create a new key, you want to use an existing key. ie, you want to import an existing key into a jks keystore.

Try the procedure on this page(s)

https://jee-appy.blogspot.com/2017/02/ssl-certificate-setup-tomcat.html

https://confluence.atlassian.com/kb/how-to-import-an-existing-ssl-certificate-for-use-in-tomcat-838412853.html

[rstevens79]

@Andrew Laden Thank you.

Looking over those they are very similar to some steps I've already taken. Step 3 above under Attempts. Instead of starting from everything broken apart we generated a P12 right from the CA. It imported fine, but after I updated the Connector for JIRA the page would never load (if memory serves me). The two outcomes we had were the page never loaded, or it loaded with a self-signed cert. My original attempts at importing a P12 did follow the guides of taking the KEY, CERT, and CHAIN and combining them, but it was unsuccessful. Figured starting right from a combined P12 would be better anyway.

I used the info form the 2nd link in my previous Attempts.

[Andrew Laden]

Interesting about the self signed cert in attempt 2. Either you are looking at the wrong file or you are using wrong alias. (I see in the "how we got it to work" section where you updated what keystore jira should use, but not in the original attempts)

Try starting from scratch with a new keystore, using the directions from the first link.

Make sure you use the full commands, in particular changing aliases when you import your certs. Ie if you generated an new keystore initially with an alias of "tomcat", then you may have a problem if you imported cert is imported using the same alias. So don't create an empty keystore first. Start by importing your CA's chain to create it. (as in the example)

In your server.xml, did you set the parameters below

 keystoreFile="<Full path to your keystore>" keystorePass="changeit" keyAlias="<Alias of the imported cert>"

I'm a little confused by your statement  " The HTTPS connector type was changed from JKS to PKCS12," Where was that changed? 

https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html

[rstevens79]

@Andrew Laden Definitely not the wrong keystore or alias. Some of the stuff I have quadruple checked. All of that is under the "Assume the following" section. All of that has been quadruple checked by multiple techs involved including myself. But I thought the exact same thing when I went through that.

Here's additional consideration which I was trying to get across in my original post. Everything works for the CSR method. The only thing that is changed throughout the entire process is the import of the certs. Everything else is identical, including the connector configuration and aliases used. Tried to keep the changes to a bare minimum so as to not introduce other problem variables.

The keystore creation is mostly pulled from Atlassian's documentation, the CLI method not the Protecle method. 

As far as the connector type, I meant to say the KEYSTORE type, not Connector type. Per Atlassians documentation they specify the Keystore Type as JKS in the Connector configuration. That is what I have changed from JKS to PKCS12 when I was using a P12 certificate. It was a last ditch effort to see if it mattered, but it didn't. None of the online forums I found indicated it needed to be done, but I was just trying different things.

I will definitely go back through the links you provided. Will have to do at a later date though as I need to finish this server now. I'm just going to use the CSR method since it works (though not preferred), then I'm going to lab this out and try anything that you and anyone else recommends.

Here's what my Connector Configuration looks like, and note that this DOES work for the CSR method:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
           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="/var/atlassian/application-data/jira/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

[rstevens79]

@Andrew Laden Definitely not the wrong keystore or alias. Some of the stuff I have quadruple checked. All of that is under the "Assume the following" section. All of that has been quadruple checked by multiple techs involved including myself. But I thought the exact same thing when I went through that.

Here's additional consideration which I was trying to get across in my original post. Everything works for the CSR method. The only thing that is changed throughout the entire process is the import of the certs. Everything else is identical, including the connector configuration and aliases used. Tried to keep the changes to a bare minimum so as to not introduce other problem variables.

The keystore creation is mostly pulled from Atlassian's documentation, the CLI method not the Protecle method. 

As far as the connector type, I meant to say the KEYSTORE type, not Connector type. Per Atlassians documentation they specify the Keystore Type as JKS in the Connector configuration. That is what I have changed from JKS to PKCS12 when I was using a P12 certificate. It was a last ditch effort to see if it mattered, but it didn't. None of the online forums I found indicated it needed to be done, but I was just trying different things.

I will definitely go back through the links you provided. Will have to do at a later date though as I need to finish this server now. I'm just going to use the CSR method since it works (though not preferred), then I'm going to lab this out and try anything that you and anyone else recommends.

Here's what my Connector Configuration looks like, and note that this DOES work for the CSR method:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
           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="/var/atlassian/application-data/jira/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

[rstevens79]

@Andrew Laden For some reason my reply keeps disappearing

[Dawn Fama]

Hello, 

If you converted your JKS to PCKS12 then in your server.xml connector you need to make sure you are referencing keystoreType "PKCS12"  and you keystoreFile should be of .p12 or .pfx vs jks.  You and also reference your truststoreFile which would be the cacerts file.