Jira behind AWS ELB with SSL offloading and http/https redirect

Ok I searched and searched but couldn't find a simple answer anywhere so dug in and I'm posting my findings hoping this will help someone else.  We're running Jira in AWS VPC behind a ELB offloading SSL to the ELB (backend VPC traffic is http to port 8080).  Everything I could find wanted additional software installed which we didn't want to do if possible.  

Below is what worked for us (may work for other Atlassian products or anything running tomcat as a web server).

Customization If running behind a AWS ELB with SSL offloading (http between ELB and server)

1. "vi  /opt/atlassian/jira/conf/server.xml" 
#Add the below in the http connector section replacing the % variable with the appropriate information
URIEncoding="UTF-8"
protocol="org.apache.coyote.http11.Http11NioProtocol"
proxyName="%external_fqdn%"
proxyPort="443"
scheme="https"

<change from> 
redirectPort="8443"
<to>
redirectPort="443"

<remove>
useBodyEncodingForURI="true"

2. vi /opt/atlassian/jira/atlassian-jira/WEB-INF/web.xml

#add the below inside of the <web-app> </web-app> section (pasted above <!-- General -->)

<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<!-- auth-constraint goes here if you require authentication -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

3. vi /opt/atlassian/jira/conf/server.xml
#add the below just above the </Host> closing argument

<Valve className="org.apache.catalina.valves.RemoteIpValve" remoteIpHeader="x-forwarded-for" protocolHeader="x-forwarded-proto" protocolHeaderHttpsValue="https" />

4. service jira restart

#3 is important (ok could have put that as part of #1) as without it you'll get stuck in an infinite redirect loop as ELB is sending http requests.

Also as the ELB won't be able to route internal traffic back in (jira server calling the ELB DNS) from the external ip address we added a hosts file entry on the Jira machines pointing to the internal ELB address.  

12/7/2017 update - the AWS ELB (ALB actually) can route traffic back in if you have a NAT gateway configured to allow the Jira server to access the internet.  We have strict egress ACL's so our Jira instance can't access the internet directly so that's why we had to use the internal ALB IP address.

Enjoy I hope this helps someone

*** Update 7/31/2018 ***

AWS finally support redirects at their ALB (ELB) so can redirect the traffic at the load balancer to https and it's a much simpler solution I don't believe you'll need any of the rewrite rules

13 comments

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 26, 2017

Good stuff, Thanks for posting this, John!

Pan Chhum December 13, 2017

You are a wonderful human being. Thank you so much for posting this. You've saved me so much time.

Mendus Chelapurath January 4, 2018

Should we use ELB or ALB? I guess ELB for SSH connections?

Also what ports are the ELB listening on?

Rick Carini March 6, 2018

Hi @john morrissey,

Thank you for this!

Can you confirm that in Step #2 you added those lines _inside_ of the <web-app * section (between <web-app and the >?

For example, in here:

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0"
metadata-complete="true"

<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<!-- auth-constraint goes here if you require authentication -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

>

This isn't correct, is it?

Thanks again!

Rick

SC DevOps April 5, 2018

@john morrissey When you created your /etc/hosts entry for the ELB/ALB, how did you format that? I'm only curious because an AWS load balancer doesn't have an IP address

Henry Auffahrt August 2, 2018

Can you explain what do you mean with your last update?

*** Update 7/31/2018 ***

AWS finally support redirects at their ALB (ELB) so can redirect the traffic at the load balancer to https and it's a much simpler solution I don't believe you'll need any of the rewrite rules

Do we don't need your solution with the new ALBs from AWS?

Henry Auffahrt August 27, 2018

Thanks a lot :) That´s awesome! :)

Simon Jones October 31, 2018

Thanks for this, John. You sure saved me a lot of head scratching :)

Yoram Ayalon October 3, 2019

Hello,

 

Regarding your update, and followup on "AWS finally support redirects at their ALB (ELB) so can redirect the traffic at the load balancer to https", it means the HTTPS is not offloaded, and you have to support HTTPS at the actual Jira host, but the whole idea is to have SSL offloading, so why is this better ? if you setup SSL on Jira might as well not use the ELB, no ?

Yoram Ayalon November 7, 2019

Great! will try this over the weekend, as sadly we don't have a non-prod instance to try this on.... 

Yoram Ayalon November 7, 2019

Oh, i remember the issue i was worried about.

Jira also also acts as the Crowd server for all our other Atlassian apps; all these apps access Jira for the Crowd config thru the internal name, and not the FQDN, thus not going out to the load balancer at all. Would this move to HTTPS for our user access break the Crowd setup?

 

Jira users: http://jira.xxxx.com

Crowd setup from all other Atlassian apps:  "jira", which translates to internal IP address in the same subnet where Jira is.

Yoram Ayalon November 7, 2019

Sorry for the repeated questions, but it just dawned on me that if,

 

  • we use the ALB to offload/terminate SSL
  • add the redirect rule on the ALB to force any external users to go thru SSL
  • allow internal access from the network with plain HTTP,

then we don't need any change in Jira! does it make sense? 

John Dondapati August 3, 2020

Thank you soo much John for this detailed article. This saved us a lot of headache. Much appreciated

Comment

Log in or Sign up to comment