glkvm.com is not working
That is your corporate web content filtering blocking the connection.
It's probably related to this:
We are currently collecting information on related issues. If the problem persists, could you please provide your device logs, the location of the control device, and your ISP's name?
Device logs can be sent to this email address (flora.wan@gl-inet.com).
We apologize for any inconvenience.
The issue is Gl.net is using an expired SSL certificate. What needs to happen is a proper ssl cert should be used. That or offer non secure connection.
You can see the SSL cert below being used. Most browsers will block it, though a lot of them will let you get around it.
Thanks for your reply
This is a device-local service certificate. It operates independently from any access restrictions on the public domain glkvm.com, so it won't affect your remote access through glkvm.com.
@FloRa Yes and the certificate is expired. This certificate that you see when you try to go to the web page on the local device. This is what the post is trying to do an not go to a public web page.
The issue is the SSL certificate on the local device exposing the web page is not valid it Expired on December 29, 1979 !!!
This need to be fixed to be valid. Thankfully Chrome & Firefox will let you bypass it.
But this is a BIG issue. Really if don’t want to deal with SSL certificates should let users enable just using HTTP instead of HTTPS.
It's not a real issue because the cert is invalid anyway. Doesn't matter if an invalid cert is expired or not.
And it's not really possible to get a cert browsers will think is valid without an FQDN (meaning you'd need to do some work as a user to buy a domain and configure things - not practical for most consumers but can be done on the KVM since we've got access to the certs). Some vendors get around this the way GLiNet is trying to by creating a public hostname and controlling the cert, for example Western Digital uses a [UUID].remotewd.com hostname and a redirect to serve up a valid cert.
I would add as well that a KVM device isn't for users without any knowledge. So they know how to bypass the cert warning - mostly.
SSL is expired, so even if I add it as root, browser and Kaspersky antivirus will ALWAYS warn me. Its annoying. Why would you add expired cert in your hardware?
There's no way to add a valid cert to a software image, the cert is there to prove that you're talking to your specific device and needs to be unique. Since you can't verify that with a stock cert, the expiration date is meaningless and you'll get an error. The right way to correct that error is to obtain and install a cert that you control, otherwise you're just trying to make something that's invalid look like more valid which isn't a great a idea.
1 Like
I find the approach to this issue dismissive of the actual user experience.
The main argument from the dev team seems to be: "It’s a local self-signed certificate, browsers will flag it anyway, and IPs change, so the date doesn't matter."
This logic is flawed for a consumer device. Here is why:
1. The "1979" date breaks the whitelist workflow
If the date were valid, I could manually add the certificate to my OS/Browser "Trusted Root Authorities" store to suppress the warning.
Because the date is from 1979, the OS and Antivirus software (e.g., Kaspersky) reject the certificate even if I manually trust it. The certificate is not just "untrusted"; it is "invalid/expired," which is a hard block for many security suites.
2. Web UI Device vs. Linux Console Skills
This device is sold with a Web UI for configuration. It is unreasonable to expect customers to SSH into the box, locate the certificate directory, and run OpenSSL commands just to fix a generation script error. If I wanted to manage certificates via CLI, I would have built a DIY server, not bought a finished product.
3. The Solution is simple
The device ships with a default hostname (glkvm.local).
-
Correct behavior: The firmware should generate a certificate with a valid date range (e.g., 10 years) for glkvm.local (CN) upon first boot or time sync.
-
Bonus: If the user changes the hostname in the UI, a script should regenerate the certificate for the new name.
Comparison of User Experience:
-
Current State (Your approach):
User sees error -> Tries to trust cert -> Fails (Expired 1979) -> Antivirus keeps blocking access -> User forced to learn SSH/OpenSSL to fix a product bug.
Result: Frustration and a perception of "sloppy" software. -
Proposed State:
User sees error -> Adds cert to Trusted Store -> Success -> No more warnings.
Result: Clean, professional experience.
Leaving the date as 1979 just because "it's difficult to manage dynamic IPs" is not a valid technical excuse; it looks like negligence. Please fix the generation script to use the current date and hostname.
So just exclude this domain from being intercepted by your "security suite"
Really the only safe mechanism is to generate your own cert, the SSH-style "generate one on boot if it doesn't exist" is OK but error prone and will still be flagged for the majority of users for not having a FQDN and associated trusted CA. There's a sliver of people who will add the cert to their browser, but most of those people know how to generate a proper cert (either self-signed using openssl, or a proper cert using a FQDN) which can then follow your own specs and not be reliant on trusting the vendor to properly generate one whenever it expires (even simple things like "should I rotate it every 30 days or every 5 years" is a very personal decision).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.