It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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

12 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?

we use ALB for jira as we use a MFA jumpbox for ssh connections as for ports 80/443 as the above redirects 80 to 443

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

@Rick Cariniyes that is incorrect you need to close the <web-app parameter with a > so in your example the > should be after the metadata-complete="true" like "metadata-complete="true">" to close out the opening <web-app

As an example all configurations need to open and close for the setting to take like the below 

<security-constraint>

All your settings and comments


</security-constraint>

Let me know if that helps

Thanks, @john morrissey - I definitely did what you suggested, because I wouldn't have expected it to work inside of the <web-app parameter.  But your instructions were slightly unclear for me, where you said "inside". 

Thank you for confirming for me!

Cheers!

Rick

ok I modified the original post let me know if it's clear now.

I would suggest the following (but I'm probably being too picky, most folks should understand this already)...

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

Oh, and thank you!

These changes have been working for us, both on JIRA and Confluence.

Rick

hum for "below the <web-app> </web-app>" technically it's between that as the </web-app> is at the very bottom of the file.  I modified the instructions a bit ago so I think that should work and if people comment I get notified and am happy to help out so we'll see how it goes.

Glad it's working for you and it helped you out

@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

@SC DevOps they actually do have ip addresses though AWS support can't see them.   We found the exact ip addresses by looking at the tomcat access logs.

With that said they do change if they fail over (AWS support couldn't tell me what would cause a failover) so it's not really the best method.

In the end our issue is we didn't have a NAT gateway assigned so anything the didn't have an elastic IP address couldn't get to the internet.  Once we fixed that we removed the hosts file entries and all worked well.

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?

Previously till about a month ago AWS didn't support redirecting http to https at their ALB loadbalancer.  I submitted an enhancement to allow the ALB to do the redirect.

This solution was to perform the redirect via jira web server which was rewriting all the urls.  Now that AWS can do the redirect technically you don't need it for external access.  Our security policy mandates end to end ssl so we still need to perform it behind the loadbalancer to ensure ssl is always used.

Here's an example of the AWS ALB redirect rule

aws_alb.JPG

Like Henry Auffahrt likes this

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

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 ?

The ALB redirects http to https on the ALB. SSL is still offloaded .

oh, you mean that if a user typed http the ALB would redirect to https ? so that should not affect the change that has to be made on server.xml ?

 

could you also possibly explain that part in server.xml - 

proxyName="%external_fqdn%"

 

What exactly i'm supposed to put there ?

 

thanks!

scheme="https" proxyName="your.alb.fqdn" proxyPort="443"

We have a CNAME for our ALB, say jira.mycompany.com, so in server.xml we use proxyName="jira.mycompany.com".

 

If you don't have a CNAME, just use the A record AWS gives you.

 

This is what the http listener redirect looks like.

@Yoram Ayalon We also use the content switching of the ALB so people can't scan the IP and get through to our jira server as we blackhole all non FQDN traffic which is a bit of security through obscurity which opening up direct access to jira directly doesn't allow for.  Also we have AWS WAF bound to the ALB for even further security

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.

@Yoram Ayalon see the below if your security compliance doesn't mandate internal traffic be https seems the redirect will work for you and your crowd should still work just fine via http internally 

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? 

@Yoram Ayalon yes now that AWS ALB supports the redirect itself you don't really need to go through the complicated setup only unless your security compliance requires it which our mandates there's no possible way to access the system via http.

Like Yoram Ayalon likes this

Now there's another issue ... how to make the redirect of Jira to be relative, because, when i try to access from outside, https://jira.xxxx.com, the ALB performs SSL termination, i get to the Jira server, Jira sends back a redirect to the login page but this redirect is absolute, thus its http://jira-xxxx.com/login-url, and of course this crashes everything. i am searching how to make the URL to the login/logout relative but for some reason this seems to be very complex. Any chance you can help here ?

 

thanks,

 

Yoram

First of all,  thanks for the help and support, especially @john morrissey  and also @Simon Hayns !

 

Changing the base URL to https://my-domain did not help.

but, this worked! i have Jira secure from outside the VPN

 

1) on the ALB. 

1.1 the request https://jira.xxxx.com is terminated by a certificate already there for *.xxxx.com

1.2 I added this HTTP (port 80) rule:

IF host IS jira.xxxx.com THEN redirect to 

https://#{host}:443/#{path}?#{query}

 

2) On the Jira server. I implemented item 3 from John's original post :

 edit <jira-install-dir>/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" />

3) started Jira. Now all working as intended!

3.1 http://jira (internal IP address within the VPN, bypasses the ALB )

redirects to http://jira/secure/Dashboard.jspa 

3.2 https://jira.xxx.com (IP address of the ALB)

redirects to https://jira.xxxx.com/secure/Dashboard.jspa 

3.3 http://jira.xxx.com 

also redirects to https://jira.xxxx.com/secure/Dashboard.jspa 

 

I guess that directive is the one that tells Jira to treat the incoming request as HTTPS by looking at the HTTP header, which is exactly what our application (and every app really) does.

Comment

Log in or Sign up to comment
Community showcase
Posted in Jira Software

Metrics Fun: 2019 in Review

Hello, Atlassian Community!  I thought it would be fun to do something different for my teams' last retrospective of 2019 so I'm planning to do a "year in review" with info-graphics.  Wha...

227 views 4 3
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you