0

Chrome V121.0.6167.185 on Win10/64

When I visit my local router at 191.168.1.1, Chrome connects with http, and shows and labels a "not secure" web site, and works correctly.

When I visit my web page explicitly at http://www.example.com, Chrome shows and labels the same way, and works correctly. (Actually, .com.au domain)

When I visit my web page just as www.example.com, Chrome tries for https, fails, shows and labels the web site as "https failed" by showing "https:" with a line through it. And then throws errors for insecure links from https to http URLs, and the links all fail. (Actually, .com.au domain)

How is it that my router is just a not-secure http website, but the web site I've built is a failed https web site?

And most importantly, how is it that Chrome thinks that the http-only web site it is showing is a https web site with insecure cross-protocol links?

1
  • Is it really a .com domain? Some top level domains like .dev are in the HSTS preload list and I would expect this behavior for them. Feb 15 at 13:44

3 Answers 3

1

Chrome (like other browsers) now defaults to https.

Better Security When Using HTTPS
As announced on the Chromium Blog, Chrome's address bar will use https:// by default. This will be available from version 90 of the desktop and Android browser, which is due to release on April 13. iOS support will follow later.

Source


When you provide an explicit address, it connects to it. When you don't it tries https and fails. It is probably because your website needs a redirect from https to http.

1
  • You think the routers we use have http redirects for the configuration pages? How would I check that? Also, is mistaking http for https a known bug in Chrome?
    – david
    Feb 15 at 3:17
1

Chrome connects to HTTPS first

Chrome tries to connect to the secured 443 port first. It gets the public certificate and then validates the certificate against a domain authority, (the site that gave you the certificate).

Chrome validates the certificate against a domain authority

If you are not connected to the internet you can not connect to the domain authority.

When I visit my local router at 191.168.1.1, Chrome connects with http, and shows and labels a "not secure" web site, and works correctly.

You are not explaining your network in enough detail. I am assuming the router is the one from your Internet Service Provider, not an additional wifi router.

When the certificate is validated by the browser

  • the browser will use the public certificate to send an encrypted message to the server (containing a new session description key) encrypted using the validated public certificate key.
  • The server will then decrypt the message with its private certificate, (which is the only key to decrypt a message encrypted by the public key)
  • the server responds with a message encrypted by the new session key that all communications for this session will use this super secret key known only by the server and the browser. Or, will respond by saying try another secret key.

SSL negotiations are completed when a secret session key has been agreed on.

How is it that my router is just a not-secure http website,

Double-check that idea ... the security protocol is fairly complex, it does not pass until the browser and server have negotiated a super secret session key which both sides have agreed on and the super secret key was created using both private and public keys.

Chrome tries for https, fails, shows and labels the web site as "https failed" by showing "https:" with a line through it. And then throws errors for insecure links from https to http URLs

The certificate likely was not validated by the domain authority.

ISP router uses a certificate that includes subdomains.

The ISP router is connected to the internet so Chrome can validate the certificate. Their certificate would be a pricy certificate that sets up every router as a subdomain so the certificate is for the main domain used by all the routers, even those the connection is on the local area network.

A non-public Intranet IP address can not get a certificate from a public domain authority

191.168.1.1 is the local address which you can not get a public domain authority to validate. Except it is possible to get a certificate for a website on a public IP address and use 191.168.1.1 as a subdomain.

It is also possible to create a domain authority server on a local area network such as used by TRW, Boeing, Lockheed Martin, et la.

Creating a local domain authority is possible, but don't do it unless you fully understand the risks associated with domain authorities.

Both the operating system and browsers need to have Local Domain Authority or DA added to their configuration. Chromebooks are the easist to setup to use a private Domain Authority ... https://support.n4l.co.nz/s/article/Installing-an-SSL-Certificate-on-a-Chromebook-Manually ... Linux and windows are needlessly complicated and may need additional software to be installed to get access to the DA records on the system. Note this is the users system, and each and everyone needs to be configured to use the private DA.

Solution given to developers

chrome://flags/#allow-insecure-localhost allows Chrome browser to ignore the fact that a connection to 127.0.0.1 is not secure or encripted and does not generate errors.

I don't like this solution because if I want a mobile app to work on a different system, not the 127.0.0.1 of the development system there is no Chrome flag to tell Chrome to treat 192.168.0.15 as a #allow-insecure-LAN.

Self-signed certiicates may work but I believe Chrome is no longer accepting self-signed certificates. A local copy of nginx would be self signed as no public DA will provide a certificate to systems which are not part of the public internet.

Workaround

One workaround, I've not tried, is to

  • create a public domain,
  • create a sub-domain for the public domain,
  • create the certificates for the public domain and subdomain. a certificate for a subdomain is the best way to go as a certificate for all subdomains is more complex and costly; while a certificate for one subdomain can be free.
  • Download and copy the keys (private and public) for the sub-domain from the public server to the server on the LAN.
  • remove the subdomain from the public server so the keys don't change.
  • repeat steps every year when the certificate expires.
  • Manually tell nginx where the keys are on the local server.
  • use hosts to set the subdomain.example.com to the local nginx server, or set up a local DNS server,

And then you can access the local server from another system as an HTTPS-secured connection, to the subdomain in the office, when you have internet access. It will be a 404 when not in the office.

If you must have access without access to the internet you must setup a local domain authority or be limited to self-signed certificates which don't work on all browser.

The workaround is basically doing what the ISP router is doing.

Although the ISP router does this automatically.

0

How is it that my router is just a not-secure http website, but the web site I've built is a failed https web site?

My website host (using nginx) returns a SSL certificate for the host. It is not valid for my URL. Chrome reports that as a broken HTTPS website.

I'm unhappy with nginx, and with my host, but it's not Chrome's fault.

Chrome then connects to my website using HTTPS, using the invalid certificate to generate the key pair. That was unexpected -- I've seen many full-page certificate errors over the years, I've had to click through warnings, browsers haven't silently connected.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.