I cannot continue setup because the http address is not secure (requires https). Therefore my browsers WILL NOT allow me to open. Does anyone have a workaround? Otherwise I’m dead in the water and cannot proceed.
It’s a ‘self-signed’ certificate. Just ignore the warning & ‘proceed.’ No issues using Chrome but its best to log in using Incognito Mode anyways. Some browser (eg: Firefox) can choke fr time to time w/ the Javascript functionality that runs when saving certain settings/buttons.
No way to proceed, browsers won’t allow, and I’ve tried three different ones. It used to be you simply got a warning and you were allowed to proceed if you trusted the site, apparently no more.
Weird.
I just updated to Brave 1.15.129 Chromium 114.0.5735.198 (Offical Build) (64-bit). Via Incognito Mode: http://192.168.8.1
The connection to 192.168.8.1 is not secure
[…]
[ Continue to site ]
I click.
This site can’t be reached
192.168.8.1 refused to connect.
[ …]
ERR_CONNECTION_REFUSED
Okay; I disable Safe Browsing within Settings → Privacy and security → Safe Browsing → No protection (not recommended) & re-launched. Same issue. I note there’s also no more option to ‘Upgrade connections to Secure’ (or something like that).
Yeah, this is a problem. @alzhao ? Can you replicate this?
The current version of LibreWolf Portable 114.0.2-1 (Firefox based, privacy hardened) via Private mode gets me to http://192.168.8.1/#/login .
It has an auto-update mechanism too so who know if it’ll eventually be like Brave/Chrome/Chromium-based ones. If you have a firewall, block it and LibreWolf-WinUpdater.exe from accessing the 'net. Windows 10 calls it Windows Defender Firewall or something similar. I’m sure you’ll find it.
At least it’s something to get you back into your GL device.
Followup: LibreWolf will still let you ‘accept the risk & continue’ if you use https://192.168.8.1
You can add the self-signed certificate on the device as a trusted certificate. Then use the intranet domain name instead of IP access.
https://console.gl-inet.com
The GL docs all refer to the IP. So does the Let’s get started. card included in the retail packaging. You guys have a problem… a big one.
Yes, yes they do. I guess I’ll have to return the unit and try another. Any suggestions on what to try? I might add that my travel device is an IPad running IOS, which I’m sure only exacerbates the problem.
1 Like
It wouldn’t matter. If the device, any device, uses a self-signed certificate it’ll be the same issue. Even if it shipped with a properly signed one eventually it’ll expire. Be it a month or a year later it would be the same roadblock.
Chrome is the predominate market leader for browsers in both desktop & mobile (2022). The only thing I can suggest related to browsers in your case is that Firefox is available for iOS. Maybe they’re not as anti-user as Google.
There is also the official GL apps for Android, iOS. I have not used them so YMMV.
This doesn’t work on my Slate AX, f/w 4.2.1-r4… but it is interesting I’m seeing this:
(I’d forgotten I removed console.gl-inet.com to set up my own custom hostname for the ATX1800)
Since most users use http rather than https for intranet connections, there is no need to use the domain. The use of IP also avoids some problems.
Will it resolve as your router LAN IP when you ping this address on the client?
Please disregard this; that’s my fault. I’d forgotten I’d removed console.gl-inet.com from my Slate AX’s hostnames. My custom hostname pings as expected. Brave, however, fails to load with the same errors as described previous for HTTP & HTTPS; hostname or IP.
Then why bring it up as a possible solution?
I think you fundamentally misunderstand what’s happening here. Until recently mainstream browsers (eg: Chromium-based ones like Google’s Chrome) offered the capability to optionally forward insecure HTTP requests to HTTPS. It mimicked the behaviour of the EFF’s HTTPS Everywhere browser extension/plugin from some time ago. In the case of Brave there was an option under ‘Privacy & security’ w/ a toggle to do that very behaviour. There is no such toggle in the latest browser update. All outgoing requests act as HTTP → HTTPS automatically, which results in → ‘This site can’t be reached / 192.168.8.1 refused to connect. / ERR_CONNECTION_REFUSED.’
I expect the same is the case of Google Chrome itself. There was mention that Google was in the process of changing the way secured connections are portrayed in Chrome. I suspect the issue described in this thread is tangentially related.
I do not have this issue when using Chromium 112.0.5615.138 (Offical Build, ungoogled-chromium) (64-bit) which is blocked from the Internet so it never recieved an update therefore can still proceed past invalid TLS/self signed certs.
I’m sure you have a GL device nearby. Update Chrome & try it yourself.
Firstly, this solution is not designed for this situation. It is simply designed to solve the problem of some users not wanting to deal with warnings every time they use https access.
For this problem, it is not possible to provide this solution to all users. It is too difficult for the average user to work with and is not applicable to mobile.
Moreover, if the browser disables HTTP access by default and prevents users from ignoring insecure certificates, it may also not allow users to download their own certificates.
Secure certificate authorities only offer certificates that are valid for a year at most, and we can’t build in a long-term certificate for devices. I think this can only be solved by providing App setup (add to User Guide) and add automatic certificate renewal feature.
This is only if really all browsers disable HTTP access to intranet IPs by default. I don’t think they do. Many intranet servers don’t need certificates at all.
In fact, I’ve tested this on Chrome 114.0.5735.199 and the latest version of Edge and it doesn’t happen.
End users as a rule, especially home users, do not have their own certificates. Most don’t know what that padlock icon even means hence why Google is changing it.
As stated 10 hours ago in this very thread:
Which is exactly why I said this is a big problem.
That would work as a solution up until the point the client doesn’t have a mobile phone which to run the app. There’s the deadlock scenario.
The browser isn’t going to care if it’s an intra/Internet IP; the biggest browser for global marketshare will still want to force the outgoing to HTTPS. See the link provided above.
The latest stable version for Chrome is 114.0.5735.205 (Platform version: 15437.61.0) released 2023-06-28. Edge stable is version 114.0.1823.67, 2023-06-29.
You have to pardon my incredulity but I don’t believe you.