Detected URL scheme, 'https', does not match expected scheme 'http'

[Steve Rhodes]

Since upgrading to JIRA 7.1.7 (from 7.0.10) I am getting the above error on my JIRA system. My test system now gives me this notification: "JIRA is reporting that it is using the URL scheme 'https', which does not match the scheme used to run these diagnostics, 'http'. This is known to cause JIRA to construct URLs using an incorrect hostname, which will result in errors in the dashboard, among other issues"

Well, we are using an F5 load balancer to terminate the SSL and then communicate with the server via HTTP. In my server.xml I have:

proxyName="jiratest.internaldomain.corp" proxyPort="443" scheme="https" secure="false"

If i access the URL directly via SSL/HTTPS then I dont get the notification. My base URL is HTTPS. I'm running this on a Windows 2008 R2 server but that shouldnt matter. It seems that the JIRA 7.1 server does not redirect to SSL and that the 7.0 server does. Can anyone help? Need any more info?

[Christian Schlaefcke]

Hi,

I am encountering the issue mentioned in JRA-60167 on my freshly upgraded JIRA 7.2.4 as well. I have exact the same configuration as in the issue - the only difference is that I am using a context path "/jira".

The upgraded documentation explains that I should be redirected to https://my.fancy-url.com/jira when I try to open http://192.168.123.123:8080/jira - but I remain on the IP/PORT address 

Is this problem maybe tomcat related? Did the configuration changed somewhere else? For sure I have 

proxyName="my.fancy-url.com"
 proxyPort="443"
 scheme="https"
 secure="true"

in my server.xml. I also tried

secure="false"

as suggested here but this is solving the issue neither. Unfortunately I also encounter this weird behaviour in Confluence and Bitbucket.

I wonder if this could be resolved somehow...

Regards,

Christian

[highrisetech]

Hello all, I'm in the exact scenario. Has anyone found a solution? I'm on version 7.5 of JIRA server.

[Manbir Kaur]

Hi All,

I am facing this issue on JIRA 6.2.7. Can somebody please suggest the solution

[Steve Rhodes]

I have a feeling that the issue is the same as in https://jira.atlassian.com/browse/JRA-60313 and https://jira.atlassian.com/browse/JRA-60167 as my HTTPS works and doesnt give an error, but if im not logged in and i access the site via HTTP, then I get the Mismatched URL Scheme error. Also this has appeared since 7.1 only and was not broken in 7.0.

[Kamal Kailasa Babu]

hello,

How did you resolved this?

Regards,

Kamal

[Steve Rhodes]

Thanks for the answer. I've had it on true and it had the same result. Plus, I found a few sources that suggested I needed secure="false" such as: (comment from Parveen)

   http://www.yasith.info/2010/07/configure-jira-40-with-sslhttps-and.html?showComment=1294400035461#c7812014602844620745

and http://confluence.atlassian.com/display/JIRAKB/Gadgets+do+not+Display+Correctly+when+Using+SSL+and+Proxy+Server

Tomcat isnt handling encryption, the F5 is. And Atlassian say "Notice in this example which shows our default connector port information secure="true". This is used when Tomcat is handling traffic over https. If Tomcat is not handling encryption, you'll need secure="false" as shown above."

Error in the atlassian-jira.log is

2016-06-17 15:41:25,088 http-nio-80-exec-3 WARN anonymous 941x4x4 kzmyhq 10.10.104.251 /rest/webResources/1.0/resources [c.a.p.r.c.security.jersey.XsrfResourceFilter] Additional XSRF checks failed for request: https://jiratest.internaldomain.corp/rest/webResources/1.0/resources , origin: null , referrer: http://jiratest.internaldomain.corp/secure/Dashboard.jspa , credentials in request: true , allowed via CORS: false
2016-06-17 15:41:26,679 http-nio-80-exec-6 ERROR anonymous 941x7x2 kzmyhq 10.10.104.251 /plugins/servlet/gadgets/dashboard-diagnostics [c.a.g.d.internal.diagnostics.DiagnosticsServlet] DIAGNOSTICS: FAILED
com.atlassian.gadgets.dashboard.internal.diagnostics.UrlSchemeMismatchException: Detected URL scheme, 'https', does not match expected scheme 'http'

[Steven F Behnke]

I'm not sure this is the only problem but secure should be set to true.