nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Steven F Behnke

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.

All comments

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.

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

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'd need to set your connector up to handle the usual SSL attributes as well. These are covered in the article you linked.

HTTPD

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.

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">

<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

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

ssl

certificate