JIRA reverse proxy with Nginx and Let’s Encrypt

We want our JIRA to work on jira.mydomain.com without the :8080 port, unlike the instructions in the Atlassian guide where it uses the path /jira. I’m hosting my JIRA server on AWS EC2 on a Ubuntu instance.

First steps are the usual when dealing with linux.

sudo apt-get update
sudo apt-get upgrade

And now we want to install nginx

sudo apt-get install nginx

I’m mostly following the Atlassian guide however it is currently a bit out of date and not very comprehensive.

 

In Jira’s server.xml config file we want to replace the line that should like:

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

with:

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

and further above look for:

<Connector port="8080" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443" acceptCount="100" disableUploadTimeout="true"/>

and replace it with the following (while replacing jira.domain.com with your own)

JIRA Proxy connector code (It’s in a file because WP breaks this code with html encoding)

Taking note that in the above that Atlassian forgot their own workaround for a Tomcat server issue. WordPress likely breaks the code above with formatting, you’ll need to copy the code from that link. It’s likely the the relaxedQueryChars section.

Now in your nginx config (/etc/nginx/sites-enabled/default) you can either edit your existing, or just delete everything inside it and start with a blank file instead. My server is only hosting jira by itself, so I don’t need to listen for any other domains. SSL config will come later.

server {
	listen *:80;
	server_name jira.mydomain.com;
	location / {
		proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_pass http://jira.mydomain.com:8080;
		client_max_body_size 10M;
	}
}

Restart your server or jira and nginx individually and your site should apear on the addresses configured above in the connector lines in the JIRA config. eg. jira.mydomain.com:8082 And now working on the hostname we configured above(jira.mydomain.com).

Now because I’m lazy and prefer to take the easy way when available. Just run through all the steps to setup Let’s Encrypt’s Certbot out of the box. It should pickup your Nginx site and auto-configure the config files for you.

Your domain should now work on https://jira.mydomain.com

If you get the warning below on the dashboard page, it’s likely because a gadget or something like the activity feed isn’t yet providing content via https. In my case it’s the latest activity from confluence (that has yet to get the https treatment) being the cause of concern.

You should get the happy green padlock on other jira pages provided they don’t have any content on those pages coming from unsecure sources too.

If you’re using AWS EC2 to run your instance, you’ll also need to remember to open up the ports we’re now using for Jira. TCP 443 to allow for https, and TCP 80 if you’re redirecting nginx port 80 (http) to 443 (https). Optionally TCP 8080-8082 to access the backup ports.

The base url in Jira will need to be reconfigured also. You’ll also need to reconfigure JIRA Server (Beta), any Application links in other software (eg. Confluence, Bitbucket, etc), and anything else that was previously using your old url (eg. http://jira.mydomain.com:8080) to the new one (eg. https://jira.mydomain.com). However in Application links such as Confluence, you’ll likely need to use the direct IP address at port 8082.

NOTE: JIRA updates seem to break this. You’ll likely need to redo this every time you update, or back up the file beforehand.