2

I host several websites via an ISP-provided DNS name, and I split them up beyond my router's port 80 using an installation of haproxy. It has worked very well for my (I think it's 11) unique websites up until I changed one of them to be https.

Now, Google Chrome assumes all my websites are https, and I can only access the one that is https :-(

I suspect the reason Chrome does this is because all my websites start with my domain name (myexampledomain.com) example site 1 would be http://myexampledomain.com/website-one/main.html and example site 2 would be https://myexampledomain.com/website-two/main.html and for some reason, after chrome successfully accessed the https link, the non-https link automatically is accessed as https. Delete the s (to make it http) and chrome just adds it back in there.

When I access my websites through Internet Explorer 9, they all still work fine, or at least can be accessed without the connection being automatically auto-completed as https. So, no, there is no http-to-https redirect somewhere on my back-end, this is just chrome being silly. Does anyone know why Chrome is being silly, and if there is a way to still access my other sites from Chrome? I hate IE, and using it causes me physical pain ;-)

5
  • 4
    Is there any chance that your SSL site is sending a Strict-Transport-Security header? There are some frameworks that automatically add them on SSL sites. Chrome supports it and IE 9 doesn't.
    – user169501
    May 4, 2015 at 14:12
  • It is very possible @Peter, but I don't know :-( how can I check? The back-end enters the router at port 443 (or port 80, the old non-https link will redirect for this one URL) and from the router is passed to haproxy, from haproxy (in the https URLs case) to gitlab (which was done from the omnibus installer, and if memory serves uses NGINX as it's hosting technology). Would this setting be part of my SSL certificate, or an SSL setting? Or would it be configured somewhere in the NGINX config of my Gitlab installation? Thanks in advance. May 4, 2015 at 14:35
  • @Peter, there is a decent chance that I asked my questions in my previous comment from a non-academic standpoint. The question I should be asking is: would, in your scenario, other sites on different machines be affected as well? My sites are spread between 3 different servers, and only 2 of them are on the machine that contains the SSL certificate and gitlab installation. This, to me, feels like something got cached by Chrome, and I would ideally like to clear that cache, and perhaps prevent chrome from doing it again... May 4, 2015 at 14:41
  • The answer is STS header, the culprit is NGINX, spelled out here: gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/… Thanks @PeterCooperJr. May 4, 2015 at 14:45
  • Strict Transport Security (en.wikipedia.org/wiki/Strict_Transport_Security) is an HTTP header that tells the browser "this server should only be accessed over HTTPS". As you've discovered, many sites/frameworks are starting to enable it automatically. You'd need to run everything on your domain over HTTPS (preferred in general on the web nowadays), or configure the site to not send the header if you actually want some parts of the domain accessible over non-HTTPS
    – user169501
    May 4, 2015 at 14:47

2 Answers 2

1

(To write up our discussion as a proper answer:)

Google Chrome (along with all other modern browsers) supports the Strict-Transport-Security HTTP Header, which informs the browser that "this site is supposed to be accessed only via HTTPS, so in the future even if the user asks for HTTP give them HTTPS instead." As using HTTPS becomes more and more common, sending this header is becoming the default in new software and frameworks, as generally if HTTPS is set up at all (which it needs to be for the Strict-Transport-Security header to have any effect), it is preferable to use it for everything. As you discovered, the software you were using is configured by default to behave this way. You did not see the behavior in Internet Explorer 9, as it is too old to support this feature of the web.

The two solutions are to either (1) change the configuration of the software to not send out the header, as you do not want to force all users to go over HTTPS, or (2) change all of your site to work properly over HTTPS. I would generally recommend the second option, as once you have the server configured and a working HTTPS certificate, there's really no need to use an unencrypted connection on the Internet nowadays.

0

As per the commentary response of Peter Cooper Jr. my heartache is caused by my NGINX installation bundled with gitlab omnibus, that effectively tells connecting clients that they should only always use https when communicating with it, and in the case of Gitlab/NGINX, the period of secure communications is set at 24 months!

Info on STS Headers: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Info on Gitlab Installation: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .