Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,465,232
Community Members
 
Community Events
176
Community Groups

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 Oct 26, 2017

Good stuff, Thanks for posting this, John!

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

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

Also what ports are the ELB listening on?

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

@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

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?

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

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

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 ?

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

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.

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? 

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
TAGS

Atlassian Community Events