why is my browser prefixing https after the initial redirect from port 8080 to 8443?

JordanJ February 14, 2021

We've configured Jira over SSL as per the instructions found here: https://confluence.atlassian.com/adminjiraserver0813/running-jira-applications-over-ssl-or-https-1027138529.html

Jira is working as expected at port 8443.  At port 8080, it initially redirects to port 8443. On subsequent attempts, both chrome and edge are prefixing https or even replacing http in the call to 8080.  Since 8080 is not ssl and should only redirect, the call fails.  It will only work once more when I clear the browser cache.  Then it wont work on subsequent tries.

This is what happens:

Step 1) http://jira:8080 --> https://jira:8443 --- As expected

Step 2) http://jira:8080 --> https://jira:8080 --- Chrome prefixes https so the server rejects

Step 3) https://jira:8443                                 --- Jira is accessed as expected

 

Is there a flag I need to set in tomcat?  I was looking into hsts but to no avail.

 

thank you

5 answers

1 accepted

1 vote
Answer accepted
KellyW
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 4, 2021

HSTS headers (Strict-Transport-Security) are enforced in a few Jira releases (8.5.11, 8.13.3, 8.14.1, 8.15.0) to address some security concerns.

To revert the behaviour back to before, we can add -Dcom.atlassian.jira.strict.transport.security.disabled=true JVM parameter to Jira startup options.

However, we still recommend having proxy server in front of Jira to redirect the traffics to the HTTPS connector (port 8443) or remove the HTTP connector connector to eliminate the redirection.


Notes: The failing redirection is due to the fact that Jira domain is added to HSTS domain security policies as Jira enforced the HSTS headers and it's hosted over non-default HTTP and HTTPS ports. This is prominent when we are using CA-signed SSL certificate (not self-signed SSL certificate as HSTS requires the certificate to be a trusted certificate).

JordanJ March 4, 2021

Thanks for this.  It's exactly what I was looking for.  I had opened a support ticket with Atlassian but they didn't know about this at the time apparently.

Dominik Žarković February 23, 2023

Hello @JordanJ

We have this same problem. Where did You add this JVM parameter? 

Thanks

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 23, 2023

For a permanent solution, you can add it to the setenv.sh/bat file in the "bin" directory.

Dominik Žarković February 24, 2023

We have add it to setenv.sh into JVM_SUPPORT_RECOMMENDED_ARGS but it didn't help. 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 24, 2023

It's not really supposed to be used in there, try adding it to the standard environment.

If it's not working, then you'll need to show us exactly what you've put into setenv.sh so we can debug it.

Tomislav Tobijas
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 27, 2023

Hi @Nic Brough -Adaptavist-

When you say

try adding it to the standard environment

what do you actually mean by it?

Also, here's the screenshot of current setenv.sh file:2023-02-27_12-53-29.png

JordanJ March 1, 2023

I think I set these values to false and http

scheme="https" secure="true"
1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 14, 2021

It's because the connection is set up to be ssl enabled.  Your browser is detecting that SSL is there, so it's changing the protocol from http to https in order to use it.

Why are you trying to use it on two different ports?

JordanJ February 14, 2021

Thanks for getting back to me.

I just followed the documentation.  It suggests an ssl port in addition. 

<Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;" 
maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" URIEncoding="UTF-8"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="false" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/>

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxHttpHeaderSize="8192" SSLEnabled="true" maxThreads="150" minSpareThreads="25" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" sslEnabledProtocols="TLSv1.2,TLSv1.3" clientAuth="false" useBodyEncodingForURI="true" keyAlias="jira" keystoreFile="<Jira_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>


 

It seems to work like this just fine in confluence.   This is the ideal scenario since we dont want user's behavior to change.  They can continue using port http://jira:8080 and all their existing shortcuts without worrying about the https prefix.  I did consider just making port 8080 the ssl port, but then we get into the existing shortcuts issue.  We have close to 500 users.

I've tried disabling the hsts flag in tomcat and blocking redirects in chrome but to no avail.

It's also curious why I don't see the same behavior after following the confluence instructions.  https://confluence.atlassian.com/doc/running-confluence-over-ssl-or-https-161203.html

JordanJ July 19, 2021

Is there an argument that can be added to a config file because this startup argument would get wiped whenever upgrading?

0 votes
JordanJ February 15, 2021

I would like to confirm the following.

  1. If you try to accomplish the same behavior while logging into the server where Jira is installed, and instead of using JIRA DNS, try using localhost:8080, what is the result?
  2. Do you have any firewall, proxy any middle system that could be changing any cookies or HTTP headers between Jira and the hosts?
  3. Have we tried to use other browsers to reproduce the issue? What is the result while using Firefox?
  4. What is the Chrome version you are using to perform the tests? I'd like to use the same version on my end.
0 votes
Aaron Robards February 15, 2021

I have exactly the same issue after updating Jira to 8.15.0 tonight, The in-built Jira redirect from HTTP on 8080 to HTTPS on 8443 was working perfectly fine with this recommended configuration until now.

Aaron Robards February 15, 2021

On further reading, this appears to relate to HSTS and sites electing to always use HTTPS. This seems to have changed in the latest Jira version?

JordanJ February 15, 2021

I've found that too and tried disabling hsts on tomcat but could not.  I changed the setting in the web.xml but the value doesn't actually change.  The only thing i could come up with is to use IIS to do redirection so that the request and responding servers are different.

JordanJ February 16, 2021

Atlassian suggested downgrading tomcat.  I won't be doing that but this was their suggestion. 

JordanJ February 16, 2021

@Aaron Robards 

Did you find a solution?  I'm working with atlassian support.  Could you describe your env?

I would like to confirm the following.

  1. If you try to accomplish the same behavior while logging into the server where Jira is installed, and instead of using JIRA DNS, try using localhost:8080, what is the result?
  2. Do you have any firewall, proxy any middle system that could be changing any cookies or HTTP headers between Jira and the hosts?
  3. Have we tried to use other browsers to reproduce the issue? What is the result while using Firefox?
  4. What is the Chrome version you are using to perform the tests? I'd like to use the same version on my end.
Aaron Robards February 16, 2021

No solution yet. Our users are having to connect direct to the HTTPS port/URL.

We are running latest version of Jira 8.15.0 with bundled Tomcat 8.5.60 on CentOS 7.9 in a GCP (Google Cloud) VM. We are not using any proxies but of course GCP has it's own firewalls.

The same re-direct configuration was working perfectly on Jira 8.14.0.

I have been testing with latest Chrome (88.0)

I can't really test properly in this environment on the Jira server but confirmed a request to localhost:8080 gives the same response as a request to JIRA DNS URL.

JordanJ February 16, 2021

Would you be willing to share you server.xml and web.xml

Suggest an answer

Log in or Sign up to answer