JIRA 7.X SSL Linux Server NO GUI

[Daniel Speck]

Hey there,

we would like to set up SSL support for JIRA, Confluence, and Bitbucket. Additionally we already have SSL certificates, signed by CA (with various subdomains, so we're not willing to refresh our certificates with some self-signed stuff).

However, every wiki page we found (this is the latest?: https://confluence.atlassian.com/jira/running-jira-over-ssl-or-https-124008.html) suggest some Windows-based solutions or, at least, requires some GUI-based solutions. We are running a clean, secure Debian server. Hence, we're not willing to install any kind of GUI.

Why is there no (official) update of the SSL plugin for JIRA? The Question: https://answers.atlassian.com/questions/33157465 is still open.

Isn't any clean command-line interface/tool available for deploying SSL certificates in JIRA?

Setting up a whole apache2, configuring virtual hosts, and setting our SSL certificates took like 15 minutes...while I've spent like one hour just for reading various Atlassian wiki pages on SSL support.

Besides, why is https://confluence.atlassian.com/jira/running-jira-over-ssl-or-https-124008.html outdated? I mean the latest version of the page covers JIRA 6.4...

We also tried to proxy to JIRA's tomcat with apache2...that solution "kind of" worked. Some elements weren't encrypted and others didn't even load (like issue filters, for example).

We're really satisfied with JIRA, Confluence, and Bitbucket so far...but the SSL-support/-setup needs to be reworked.

[Steven F Behnke · Accepted solution]

Perhaps you're unfamiliar with how SSL termination typically works in Linux? I could help more if you tell me what method you're planning to use...

Tomcat

You need a keystore. You use the key and certificate, as well as trusted certificates to create a keystore using whatever tool you like, I usully get what I need done with keytool or openssl. Then you can reference the keystore and password in the configuration file, located at path: install-dir/conf/server.xml

You'd need to set your connector up to handle the usual SSL attributes as well. These are covered in the article you linked.

HTTPD

You need to place the certificates and keys in known locations and reference them in the ssl.conf file within the HTTD configuration location. Then you ensure you've set up the proper connection proxy information to JIRA within the httpd.conf file. This is the httpd server configuration.

If you're getting missing pages or weird stuff when setting up the proxy, you probably didn't change the install-dir/conf/server.xml configuration file to indicate you were going to proxy the connection.

[Daniel Speck]

Thanks for the addition.

To clearify this (I think config files are better than words/paraphrases):

/etc/apache2/sites-available/subdomain1.domain.conf

<VirtualHost *:80>
        ServerName subdomain1.domain.tld
        ServerAdmin admin@domain.tld
        ProxyPreserveHost On
        ErrorLog ${APACHE_LOG_DIR}/subdomain1.domain.error.log
        CustomLog ${APACHE_LOG_DIR}/subdomain1.domain.access.log combined
        Redirect permanent / https://subdomain1.domain.tld
</VirtualHost>
 
<VirtualHost *:443>
        ServerName subdomain1.domain.tld
        ServerAdmin admin@domain.tld
        SSLEngine On
        SSLCertificateFile /etc/apache2/ssl/cert.pem
        SSLCertificateKeyFile /etc/apache2/ssl/privkey.pem
        <Proxy *>
                Order allow,deny
                Allow from all
        </Proxy>
        ProxyPass / http://127.0.0.1:8080/
        ProxyPassReverse / http://127.0.0.1:8080/
        ErrorLog ${APACHE_LOG_DIR}/subdomain1.domain.error.log
        CustomLog ${APACHE_LOG_DIR}/subdomain1.domain.access.log combined
</VirtualHost>

/opt/atlassian/jira/conf/server.xml

(...)
<Service name="Catalina">
<!-- Apache Proxy Connector -->
<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" port="8080" protocol="HTTP/1.1" redirectPort="8443" useBodyEncodingForURI="true" scheme="https" proxyName="subdomain1.domain.tld" proxyPort="443" secure="true"/>
(...)

With this configuration, JIRA does not complain that tomcat might be configured incorrectly and most pages are working. However, some avatars are gone and the heatmap gadget on the dashboard refuses to work, some other gadgets are broken (like weird titles, buttons without labels, ...), some other are working. Everything else (as far as I can tell) is working without errors.

[Steven F Behnke]

I'm cool with using apache, I just want to know why you're set on using it. It's technically another application to maintain and administer? Anyway, I see nothing explicitly wrong with the configuration presented. You've updated the Base URL, correct? It's subdomain1.domain.tld, correct?

I'm curious, what do you mean by "gone" and "refuses to work?" In this case, you'd usually be tailing the application log and navigating to pages that don't function correctly. If it's a server issue, usually you can rely on something being printed there when you call that page or action – If it's client side, you can usually rely on seeing a 404 or 500 in the browser console.

[Daniel Speck]

The baseurl is set to https://jira.domain.tld. This should be correct?!

We use apache2 because of several reasons:

• no prior experience with Tomcat (some of us were Java programmers, but none has experience with Java web development via Tomcat. We're developing applications with C++ / Cython / Python).
• JIRA, Confluence and Bitbucket are running on a big root, which already had an Apache up and running. Several other vhosts with other stuff are set up there with SSL support. Therefore we thought integrating in our existing infrastructure should be a good idea.
• we do not want to bother our customers nor our employees with ports. Apache offers it's nice proxy passing for redirecting and eliminating the ports
• the JIRA over SSL page (https://confluence.atlassian.com/jira/running-jira-over-ssl-or-https-124008.html) for configuring Tomcat directly is outdated. Latest supported versions says 6.4.
• the documentation seems to expect the admin to use GUI-tools for key converting, for configuring and so on. We don't like GUI-tools for admin stuff.

I will check the logs in the next days. By "gone" I mean that some avatars couldn't be loaded after the configuration and had to be re-uploaded. The heatmap gadget on the dashboard displays no data at all, so completely stopped working. Some other gadgets are broken, like having this __MSG_gadget.activity.stream.title__ instead of the correct title, or no title at all. Some gadgets' buttons have no labels now. Despite these two things (gadgets and avatars) everything else seems to work without errors - so far.

[Steven F Behnke]

The guide you've posted is for beginners. I would totally disregard the GUI suggestions and I agree, they seem odd. I use command line tools only when terminating SSL on Tomcat. You are free to follow any method to terminate SSL in Tomcat or Apache. They've stopped creating the articles, as you've noticed – It's not "out of date."

You'll notice the big yellow warning on that page you provided that states the following – 

Atlassian applications allow the use of SSL within our products, however Atlassian Support does not provide assistance for configuring it. Consequently, Atlassian cannot guarantee providing any support for it.

So, Atlassian doesn't officially support SSL, it's such a generic concept and you can do it so many ways it's not really in their offering. That's all i meant.

You are totally fine in using Apache HTTPD. In fact, you gave many reasons in which I would also decide to use Apache HTTPD, thanks for the detail. I just see so many people do so without good reason.

So, I think we're on the same page so far.

Based on your answers and posted configuration files, I think you've set the proxy up correctly. I think you've configured the application correctly. But we still have an issue. I've been able to locate RECENT issues that have only recently started occurring – 

Related Question: https://answers.atlassian.com/questions/24649645Related KB Article: https://confluence.atlassian.com/jirakb/how-to-fix-gadget-titles-showing-as-__msg_gadget-813697086.html

I think the issue here is that modules inside of JIRA that access JIRA externally are not resolving your proxy. Someone posts a workaround in the related question – 

For me the problem was the JIRA application was not able to find the JIRA-url via https. Because the JIRA application is on the same network as the proxy server it is not able to use the external proxy IP. I added the internal proxy IP with the URL name to /etc/hosts which solved the problem for me.

The entry I added to /etc/hosts is like:

192.168.x.y jira.<domain>.<tld>

[Daniel Speck]

This looks very similar to our gadgets. Thank you very much, I will try the solution.

[Daniel Speck]

Too bad, it did not work 

I've tried the ip address of our network interface as well as 127.0.0.1 for the ip part and jira.domain.tld for the hostname.

[Daniel Speck]

In case anyone has the same issues in the future: Steven Behnke's basically solves the problem.

There is only one additional thing (absolutely essential!) if you want to enable SSL via Apache: JIRA (see catalina.out) complains, if Tomcat does not have the very same SSL certificates the Apache webserver is using. Thus, you have to manually add the certificates to Tomcat.

If someone needs help with this, contact me and I'll can add some information (I've written a shell script for automating this stuff).

[David Swanson]

Hello Daniel,

I am looking into solutions for setting up out Atlassian suite with SSL and would very much like to check out the information and script that you have written up on this subject. 

[Steven F Behnke]

I'll continue answering on the other thread, so as to keep conversation in one spot.

[Daniel Speck]

When Atlassian doesn't support to set up SSL, with or without tomcat (I'm not familiar with tomcat), why does the GUI-stuff on https://confluence.atlassian.com/jira/running-jira-over-ssl-or-https-124008.html supply a solution to somehow convert certificates and set up a keystore path? Sounds confusing to me.

However, we've set up our Apache (were numerous other vhosts are running) with SSL. We configured Tomcat according to: https://confluence.atlassian.com/jira/integrating-jira-with-apache-using-ssl-203395380.html

Without the tomcat configuration, some issue filters are not working, the dashboard is broken and so on. Additionally JIRA complains and tells us to configure tomcat, because we're probably using an apache proxy and didn't configure tomcat appropriately. So far, so good.

With the configured server.xml JIRA is not complaining anymore - it seems to work...but some profile avatars are gone and the heatmap gadget on the dashboard refuses to work. Besides this, all other pages are working (as far as I can tell) and, according to Chrome, secure.

[Steven F Behnke]

Also, if you're proxy isn't loading all the pages, you've set it up wrong. We can't help you troubleshoot unless you post your configuration details and any errors you're receiving relevant to this issue.

[Steven F Behnke]

I guess I'm confused – You should terminate SSL any way as a system administrator you feel you should. JIRA, Confluence, and Bitbucket are all applications running through Tomcat. What's the question here? You sound familiar with Debian and OS administration.

Either terminate your SSL connection in Tomcat, continue proxying to Apache and terminate SSL there, or handle it another way. It's 100% external to the application and is really more of an system topic rather than an application topic; Atlassian doesn't support SSL configurations as such.