684

I had something set up wacky in our DNS setup which is now resolved.

The remaining problem is that chrome has cached the incorrect setup.

Specifically, when using Chrome http://example.com is now redirecting to https://example.com (naked domain), which is not valid/supported. http://example.com SHOULD redirect to http://www.example.com and then force https://www.example.com.

But on a handful of browsers (including mine) this doesn't happen because of some funky Chrome caching. I tried going to “Privacy -> Clear Cache” but it had no effect.

phil swenson
  • 6,949

12 Answers12

1000

In addition to cached redirects, HTTP Strict Transport Security (aka HSTS) may be at play. HSTS is a security feature that forces the browser to use HTTPS even when accessing an HTTP URL.

The browser will start using HSTS for a domain after receiving a Strict-Transport-Security header from the server. The browser also ships with a list of domains for which HSTS is enabled by default.

In Chrome, there is a way to delete your domain from HSTS after it was added by the server. Though, you can’t exclude domains that are baked in the browser (this includes popular websites and notably everything under the new .dev TLD)

  1. Go to chrome://net-internals/#hsts. Enter example.com under Delete domain security policies and press the Delete button.

  2. Now go to chrome://settings/clearBrowserData, tick the box Cached images and files and press click the button Clear data.

ducpho
  • 10,125
267

My problem came from having a .dev domain, which was apparently recently registered as a gTLD and put in a commit to Chrome Canary. I found this out from a recent post I came across as I searched for my problem.

If you have the same problem I do, it appears that the best solution is to change your domain to be something other than .dev. The article suggested .test with a potential solution of .localhost later down the road (via this proposal).

33

To delete domain under "HSTS" menu in chrome://net-internals is a temporary solution. After visiting this domain over HTTPS it will be included in HSTS list again.

Basicaly, to solve this issue it is necessary to disable HTTP Strict Transport Security on the web-server 3rdrevolution.com (IIS, Apache, nginx,...). For nginx edit its HTTPS section in nginx.conf and set 'max-age=0' for Strict-transport-Security:

server {
#...
        ssl on;
#...
        add_header Strict-Transport-Security "max-age=0;";
#...
}

More info: HTTP Strict Transport Security (HSTS)

Uwe Keim
  • 2,112
22

https://www.3rdrevolution.com sends the Strict-Transport-Security header so accessing it over https once will make browsers like Chrome/Firefox redirect http requests to https until some specified point in the future.

As the other answer said, the only way to stop this once it starts is to clear the browser cache (or wait for the browser to expire the order).

gronostaj
  • 58,482
Anon
  • 1,431
16

From https://galaxyinternet.us/google-chrome-redirects-localhost-to-https-fix/

None of the option fixes worked for me, for fixing https://localhost:3000, this did.

Click and hold reload button and select “Empty Cache and Hard Reload,” this seems to only be an option on localhost.

Screenshot of the “Empty Cache and Hard Reload” option.

Giacomo1968
  • 58,727
15

There could be a couple of reasons for this, including plugins but assuming that you do not have any plugins installed you can do the following:

Goto Settings/Privacy/Clear Browsing Data...

Select The Beginning of Time in the pull down.

Select:

  • Clear saved Autofill form data
  • Delete cookies and other site and plug-in data
  • Empty the cache

Select Clear Browsing Data

This should take care of it doing any Auto-fill based on your previous browsing. Also, it will remove any of the cookies that could also be causing problems.

Atari911
  • 768
  • 5
  • 11
7

If you are facing the problem on a subdomain then this line in Nginx might cause a problem even if the subdomain is in another server, as the browser will cache this information.

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

so remove the includeSubdomains; of it to make it work.

khelll
  • 383
6

A less drastic alternative than clearing all cookies ever is Settings>Show advanced settings>Content Settings>All Cookies and site data then search for the sites in question and clear cookies for only those.

5

Before few days I accidentally turned on Chrome options named:

  • Automatically send some system information and page content to Google to help detect dangerous apps and sites
  • Protect you and your device from dangerous sites

And now the main problem was that our website on subdomain always redirect from http:// to https:// and browser gave me an error:

"Your connection is not private. Attackers might be trying to steal your information from censored.censored.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID"

Open chrome://settings/privacy and turn previously named chrome options that automatically protect your devices. Hope this will help someone.

2

in Chrome 66, lots have changed in the Settings tab

you can just go to chrome://settings/resetProfileSettings?origin=userclick then hit reset.

this worked for me.

nljms
  • 37
2

Using Firefox v129.0.1 in 2024, what worked for me to prevent redirecting http://localhost to https://localhost was:

  • go to about:config
  • search for the key browser.fixup.fallback-to-https
  • set it to false

I suspect that this will run into some side effects, but I need to get to localhost.

0

For me developer mode was the answer. (Ctrl-Shift-I, long mouse press on "reload" icon for making a menu appear, "empty cache & hard reload".)

I have to guess, but cleaning even HSTS downloaded data (=files?) seemed to have killed some buffered automatism that always caused a http to https change even before the first real server access for the given input was done.

https://stackoverflow.com/questions/38968510/how-to-permanently-exclude-localhost-from-hsts-list-in-google-chrome