Hey guys,
Can you share a guide on how to fix the SSL certificate for the KVM? Didn't find any in this forum.
Currently, I'm being blocked to connect to it from a external connection because of that. I don't mind being a self assigned cert.
Starting from version 1.4.0, SSL certificates are stored in /etc/kvmd/user/ssl.
Q. What's better than a self-assigned cert?
A. Your own, private certificate authority.
I'm certainly not going to install some random root certificate on my computer—that's way scarier than any warning pop-up.
You don't know what private certificate authority means, do you? That 'app' is a wrapper for custom root cert gen by OpenSSL.
That software is also more F/OSS than anything GL.iNet currently ships. I'd say running closed source software from CN is far more concerning.
So someone has managed to get this setup for the routers: How-To: Let's Encrypt on GLDDNS domain
But doesn’t seem like this works for the KVM, even the install commands that the script is calling to install an ACME script (opkg) doesn’t seem to be on the KVMs. So I’m hopeful someone will figure out how to get something similar working on the Comet at some point.
The reason someone might run an ACME script on a router is that the router may obtain a public IP address. an ACME script requires the device to have a public IP and prove ownership of it via ports 80 and 443. However, GLKVM is unlikely to obtain a public IP. If you plan to forward the KVM's ports 80/443 through the router, why not simply generate the certificate on the router and then copy it over for use?
FWIW, certbot/Let's Encrypt allows you to generate certs by adding a DNS TXT record instead of pulling a file off the webserver itself. It can even hook into many DNS service providers if they support an API (like Cloudflare). Using this on a computer and then using scp to copy the certs over to the Comet may be easier.
I have MULTIPLE internal LAN-only services on my network with ACME certs issued via DNS challenge, including on two separate PiKVMs. The PiKVM documentation not only includes documentation for setting up Certbot (the ACME client), but also for configuring it with several DNS providers (such as AWS’s Route53, which I use): Let's Encrypt certificates - PiKVM Handbook .
So “public IP” is irrelevant here, what matters is the DNS name, and as long as you’re updating publicly-accessible DNS for the ACME challenge, you don’t even have to expose the internal DNS landscape (my internal DNS that holds the A record for the KVMs isn’t publicly accessible, but I have an external zone that’s valid for the names that the TXT records for the challenge can be set and accessed by ACME CAs).
The primary issue is I’d really love to NOT have cert warnings for internal services, otherwise, why even bother with HTTPS at all? All my other internal services (PiKVM, Jellyfin, Home Assistant, MQTT, Proxmox, Zigbee2MQTT, etc) have DNS-challenge issued TLS certs from ACME. There’s no reason that this device couldn’t do the same.
If you’d like, you can actually browse/search Certificate Transparency logs and see all the certs I’ve requested for everything on my home network: https://crt.sh/?q=home.brwyatt.net . The real fun here - all of these were using DNS validation. SOME are actually externally accessible, but via an inbound proxy, which is why there are duplicates (or more!) of some certs (each distinct host that can serve the name has it’s own unique cert, and I have multiple inbound proxies, and also multiple internal proxies for multi-host services). But, of note, none of the KVM or Proxmox related names are resolvable outside my network; however, the TXT record for \_acme-challenge.<host>.<vlan>.home.brwyatt.net was, momentarily, resolvable as part of the certificate challenge process.
So there’s no technical reason that the Comet couldn’t do similar here, other than just the binaries/scripts for making it easy aren’t available. Could probably hack it together or, as jdbower suggested, just have some other host do it an SCP it over, but unless that can be automated (haven’t poked enough to see if the Comet actually support SSH), it’ll be a bit painful doing that every couple months. (But at least, in theory, it should be easy enough to write a hook for it)
The Comet does support SSH out of the box so I've never looked further at automations on the device. I've got a script on a central system that checks all of the certs configured for expiration dates, updates those about to expire, and then uses SCP to push the certs to any standalone devices and reset the webserver if needed/possible. I found this process to be more scalable across a multitude of devices, including smart power strips, the Comet, etc. Of course, my NGINX reverse proxy shares a filesystem folder so that just needs a restart every so often when the symlinks change.
The biggest issue I see is that the default self-signed SSL certificate is improperly generated.
It has no SAN, so it can’t be used in any modern web browser. It also doesn’t match the hostname of the actual device set in the settings; it’s just “localhost”.
Since the latest firmware update provides the ability to change the hostname, it should automatically generate a new SSL certificate immediately when the name is changed with the FQDN in the cert’s SAN. This would make it much easier to trust the self-signed certificate.
Or just use tailscale to get a browser default trusted cert from lets encrypt. you can get a cert by using “tailscale cert ”. Then just put them in /etc/kvmd/user/ssl as server.crt and server.key. reboot and done.
Just got the Comet KVM; pretty cool bit of kit for sure. I was able to setup ZeroSSL certificates on the device and they seem to work. Directions on my github gist and open to edits and suggestions.
I suggest you copy, rather than link, your certificate; otherwise, you might become the next user on the forum complaining that we didn't save your certificate after upgrade.
That is fair; I left it as a link so that when the certificates renew, that they will automatically be valid.
Does the root directory get wiped during upgrades? If so, that is something I will definitely keep in mind.
Will be wiped
FWIW, I use links for my certs as well as it makes things much easier. But I keep them all in the same directory and do a cleanup of older certs manually.
Circling back around, since I finally got some time to setup something to push ACME certs from Let’s Encrypt to the device over SSH. It’s a Jinja2 template (since it is used from Ansible), but in case it helps someone else trying to get real certs on the Comet KVM that don’t give warnings…
Hi, if anybody is interested I created a script to install certbot and fetch a Let’s Encrypt certificate using Cloudflare DNS plugin (DNS challenge).
To use it you need to create an account on cloudflare_dot_com, import your own domain there, create a A record for your glkvm (for example: glkvm.example_dot_com), create an API token that can edit your DNS Records (use the template permissions for it).
Then run the script as ssh [email protected] 'bash -s' < setup-certbot-glkvm.sh ``glkvm.example.com`` YOUR_CLOUDFLARE_API_TOKEN1
Script is here: Proper certificates for for GLKVM Comet (Pro) using Certbot · GitHub