It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Installing SSL in JIRA

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

6 answers

1 accepted

5 votes
Answer accepted

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

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.

Like Sebastian Golombek likes this
Like # people like this
Like # people like this

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

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!

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.

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

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. 

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!

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.

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?

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

@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?

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.

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

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.

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>

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

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\

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?

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)

How did this work out for you?

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. 

Like Salvatore_Manganella likes this

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

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

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?

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

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you