Installing SSL in JIRA

[Gregory Hicks]

Hey everyone,

I have been tasked to make JIRA work using HTTPS. I have found a few articals in reguards to this but they're over my head. Here is my situation,

We already have a cert purchased and on the server ready to be applied, I am using version 4.2.4 on a 2008 windows box. Jira is serving under apache which I am not totally familure with. The changes that need to be made to the Server.xml file I don't see being an issue, I just have no idea how to apply the cert to jira/apache.

This is my frist time doing this so please excuse the stupid questions I may ask.

Thanks

Greg

[Deleted user · Accepted solution]

Hi Greg,

Have you read through the following? Following this worked for us. Might want to check with your cert provider on entering the cert to the keystore.

http://confluence.atlassian.com/display/JIRA044/Running+JIRA+over+SSL+or+HTTPS

[Gregory Hicks]

Yes, that was the one I was trying to follow. I started creating a Key but I already have a cert. I just don't know if I need a keystore if I already have a purchasecd wildcard cert sitting on there server.

[jobinjames]

https://blog.technets.in/install-ca-signes-certificates-in-atlassian-products/

[Junio Fernandes]

@jobinjames HTTP 404

[Ivar]

This can be quite easy or hard as h*ll :) I've been through it a couple of times and the following turned out OK for us.

Prerequisite: the certificate comes as a pfx file.

The following commands will:

1. Import the certificate from the pfx file into our default java keystore
2. Specify the password for the default keystore (should not be necessary - however I did it just to make sure)
3. Get the name of the new alias as I did not specify an alias name in command 1 (normally a guid)
4. Change the password for the new alias. NB - the pfx will most likely come with a password. This password will be used as default password when Java tries to use this alias/key. You do not have to change the password but then you need to make sure that the pfx password is the one you specify in Jira when you configure the system to run over SSL

I've seen that the server is happy for a restart when the keystore gets a new certificate. Do not know if this was really necessary though.

The keytool is available in your default java directory\bin folder if I'm not mistaken.

keytool -importkeystore -deststorepass changeit -destkeystore D:\Java\jdk1.6.0_26\jre\lib\security\cacerts -srckeystore D:\Atlassian\Atlassian.Security\certificate.pfx -srcstoretype PKCS12 -srcstorepass yourPfxPassword
keytool -storepasswd -new changeit -keystore D:\Java\jdk1.6.0_26\jre\lib\security\cacerts
keytool -list -keystore D:\Java\jdk1.6.0_26\jre\lib\security\cacerts
keytool -keypasswd -alias {alias_from_the_last_command} -new changeit -keystore  D:\Java\jdk1.6.0_26\jre\lib\security\cacerts

[dknoodle]

This was freaking awesome and made it go incredibly fast. The last time I had to do this took me hours. This walkthrough saved me So much time! Thanks!

[Vision Integrated Graphics]

Just wanted to add a big thanks, these instructions were a a million times easier to make sense of than the stuff over on "how to configure SSL" page they provide.

[casupport]

Thanks for the walkthrough, this got me going in short order. Congratulations on mastering something not even Atlassian understands.

[Mary Preziosi]

Thank you!!!!!!!!!!!!!!!! So easy. i understand exactly what I'm doing now when I use keystore. Before I was just typing commands and hoping they would work. 

[Michael Woffenden]

A few years later Ivar, but your 4 line solution worked wonders for me!  1000 THANK YOUs!

After going around in circles for an embarassingly long time -- and trying to follow Atlassian's official documentation, this post saved my sanity!

Note that my PFX file was simply an export from an existing IIS cert ... and it worked like a charm.

I'd like to add that an important part for me was to focus on using the JRE provided by JIRA, rather than installing Java externally, which was not needed.  Furthermore, the several pages of Jira documentation suggests creating a separate keystore, which also turns out to be not necessary.  And furthermore, creating the separate keystore also added complications.

At the end of the day it was as simple as importing my existing certificate to the default Java keystore used by Jira using those 4 keytool commands!

[TechShare]

our server.xml file in confluence does not reference any keystore. The keystore referenced in server.xml for jira is not actually there. Any suggestions. we have a working SSL certificate that our hosting provided updated last year without touching any keystore but this time around we encountering thus issue and Atlassian just keeps telling us to update the ketstore.

[Michael Woffenden]

Hi TechShare - When did the issue start happening?  What error(s) are you seeing?  Were there any changes at all on the server recently?  Can you attach a screen shot of the errors?

[Sherif Abdelfattah]

Guys, Although the above solution might be working at times, but it actually not recommended to add private key data in the cacerts file.

cacerts is a truststore populated by public certificates used by JIRA to verify SSL trust, is not supposed to be used as a keystore.

The keystore should be a different file than cacerts.

Please check the Java documentation about this: https://docs.oracle.com/cd/E19830-01/819-4712/ablqw/index.html

[Michael Woffenden]

@Sherif Abdelfattahwould you please elaborate on this?  I looked at the referenced article and did not see a statement that the keystore should be a different file than cacerts.

We're currently using cacerts for the SSL certs, should we switch to creating a separate keystore file -- and why would it make a difference?

[Justin Pier]

We started with a separate keystore for our wildcard certificate, but after we renewed the certificate the Gadgets stopped working.

We did two different things to try and resolve this... but I'm still not sure which one actually resolved the issue.

We updated the cacerts keystore with a newer intermediate certificate, but that didn't seem to have any impact.

Then we followed Ivar's suggestion of loading our PKS into the cacerts, and changing the password for that key to match the cacerts password.

We were using the HTTPClientTest.jar, locally on the server, to verify if server would trust the certificate when it calls itself (cuz this is how the Gadgets work).

This was returning an error that it did not trust the certificate.

Michael Woffenden (in the thread above) made a note "to focus on the jre provided by jira", and that made me realize I had been updating the wrong cacerts file.  I was updating the one in my Java folder, rather than the one in my JIRA jre folder.

If I would have taken my time, and just updated the cacerts with my intermediate and then tested, I would know if that was all that I needed or not.

Since I did both prior to testing... I will just have to wait until next year to know if it was necessary or not.

Either way, my problems were solved, so I can't complain.

Thank you Ivar.  Thank you Michael.  And thank you Community.

[Tommy Jones]

The documentation for this is pretty shoddy. This is they way I did it...

Open CMD, type the following commands

cd 'C:\Program Files (x86)\Java\jre1.8.0_201\bin'

.\keytool -importkeystore -deststorepass cert_pwd -destkeystore 'C:\Program Files (x86)\Java\jre1.8.0_201\lib\security\cacerts' -srckeystore 'C:\Program Files (x86)\Java\jre1.8.0_201\lib\security\cert_name.pfx' -srcstoretype PKCS12 -srcstorepass cert_pwd

cd C:\Program Files\Atlassian\JIRA\bin\config

.\config.bat

* the JIRA Configuration tool will open

Select the Web Server tab and enter the details from above

Reboot the server

[Ryan Coup]

Ivar Sønstabø has the correct answer.

I've been searching the internet for hours to find how to import my wildcard certificate to be used in Confluence.  Ivar had the correct answer.  It dumbfounds me why Atlassian doesn't have clear step-by-step instructions on how to install certificates for various operating systems and in different situations.  Import a certificate vs. applying for a new certificate.

I think what most people don't realize is that there are two different passwords in the keystore file; one password for the keystore file itself and then another password for the certificate contained within the keystore file.

Use the commands that Ivar posted above to change the passwords for both.  Then you can follow Atlassian's instructions to use the keystore file in Confluence or Jira.

Thanks again to Ivar!!  Wish I could by you a beer, or the drink of your choice.

[Richard Hup]

This tread is a bit outdated, best to use this solution.

Difference with what I found here is that the certificate alias must correct, and there's no need to convert PFX files, you can specify them directly. To do that using the graphical config tool in Linux, assuming Jira installed at /opt/atlassian:

1) Upload .pfx file to:
/etc/ssl/localcerts/mycertificate.pfx

2) Get the alias:
/opt/atlassian/jira/jre/bin/keytool -list -keystore /etc/ssl/localcerts/mycertificate.pfx

For my certificate it had format: xx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

3) Install and run Xming server on PC, connect with putty X11 forwarding exabled, login as root

4) Run Jira config tool:
export JRE_HOME=/opt/atlassian/jira/jre
/opt/atlassian/jira/bin/config.sh

5) Update config on tab Web Server:
Profile -> HTTP and HTTPs (redirect HTTP to HTTPs)
HTTP Port -> 80
HTTPs Port -> 443
Keystore Path -> /etc/ssl/localcerts/mycertificate.pfx
Keystore Password -> (your pfx password)
Key Alias -> (your certificate alias, step 2)

6) Save and reboot

7) I had to resolve this issue

[Maciek Grischke]

It's scary how old this thread is and the process is absolutely stupid...

[Anthony France]

Tomcat is the webserver Jira runs on.  If you're running Jira locally you should be capable of administering a Tomcat install.  This is how you manage a certificate on Tomcat servers.  

Would it be stupid if you had to install the cert into IIS the IIS way if it used IIS?

[Maciek Grischke]

The process is much easier on other platforms. The way this is done in Jira is ridiculous. 9 years later...

[Ivar]

How did this work out for you?

[TechShare]

this is ridiculous

atlassian says we need to update the keystores yet these keystores don't seem to exist and server.xml references no keystore. 

[Anthony France]

You just install and manage SSL the same way you would any other tomcat/JAVA webserver.... 

[Remon van G]

Realise that you may have a cert/key for the outside world to communicate with your apache, but that the connection from apache to jira can have its own cert/key (and keystore).

With former jira versions (now we are on 4.4) we had issues with the ajax components and https, so we implemented a reverse proxy with apache2. Because of this we can keep jira 100% at a default setup with a self signed certificate and handle the outside SSL with the company cert.

We use linux, but the apache setup should not be all that different, this is how we did it in apache (cleaned up version)

I hope it is helpful for you.

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName jira.yourdomain.com
        ServerAlias www.jira.yourdomain.com

        RewriteEngine On
        RewriteRule ^/(.*)      https://%{HTTP_HOST}/$1 [R]
</VirtualHost>

<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        ServerName jira.yourdomain.com
        ServerAlias www.jira.yourdomain.com

        SSLEngine On
        SSLCertificateFile    /etc/apache2/ssl/yourdomain.com.pem
        SSLCertificateKeyFile /etc/apache2/ssl/yourdomain.com.key
        SSLCertificateChainFile /etc/cert/STAR_yourdomain_com.ca-bundle

 # JIRA is running on port 8080/8443 local on xxname, so we could just proxy it here in Apach$
        SSLProxyEngine on
        ProxyPass / https://localhost:8443/
        ProxyPassReverse / https://localhost:8443/
        
        ProxyPassReverseCookieDomain xxname.yourdomain.com jira.yourdomain.com
        ProxyPreserveHost On

       
        #DocumentRoot /home/www/
        ErrorLog /var/log/apache2/jira.yourdomain.com-error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/jira.yourdomain.com-access.log combined
        ServerSignature On

</VirtualHost>

[Gregory Hicks]

So I was able to get the cert imported sucessfully!

Where is this file located, the only file I have changed is the Server.XML. What I have so far:

<Connector port="8443" maxHttpHeaderSize="8192" SSLEnabled="true"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"

acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"/>

============================================================
<!-- <Connector port="8009" redirectPort="8443" enableLookups="false" protocol="AJP/1.3" URIEncoding="UTF-8"/>
-->

<Engine defaultHost="jira-stage.icfwebservices.com" name="Catalina">
<Host appBase="webapps" autoDeploy="true" name="jira-stage.icfwebservices.com" unpackWARs="true">

<Context docBase="${catalina.home}/atlassian-jira" path="" reloadable="false" useHttpOnly="true">

============

This is the only file that the directions say I need to change but everytime I try to hit the site it fails to load as https: Now when I try to hit it no Https I get this error.

HTTP Status 404 -

--------------------------------------------------------------------------------

type Status report

message

description The requested resource () is not available.

--------------------------------------------------------------------------------

Apache Tomcat/6.0.20

[Remon van G]

Check your catalina.log file.

It might say something like 'unable to open cert' bla bla etc

The tomcat tries to read the key file from the root of the users home folder that runs the server. If you would be on linux this would be /home/jira (running as user jira), in windows perhaps c:\Users\administrator\

[Gregory Hicks]

So I am like 100% sure now there is a file somewhere that needs to be changed. When I tried to hit the old DNS it came up as this (http://https.jira.stage.icfi.com/) I just don't think I have changed all the DNS records to the correct URL.

==============

So I got the site to repond by removing the redirect stuff in the Web-INF/Web.xml file. So http://jira-stage.icfwebservices.com is now working but I can't seem to get the HTTPS to work. I have followed the directions giving by JIRA to a T and i'm at a loss as to why it's not working. I have the Cert and Key in the jre/bin folder, not sure if that makes any difference or not. If so I don't know which file to edit.

Any Ideas?

[Ivar]

Have you imported the certificate to the keystore as I described below? Have you 'told' Jira to use this imported certificate by specifying the alias in the https connector in server.xml:

keyAlias="{87ed6798-4f39-45c7-8f39-3d1d309e25f1}"

(you use the alias created by the import of the certificate of course)