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.
.comdomain? Some top level domains like.devare in the HSTS preload list and I would expect this behavior for them.