Comment by xmprt 3 days ago
I'm sure some people would find this useful but forgive me if I'm not ready to hand away my security to some unknown third party company. I don't know the first thing about CAs but Let's Encrypt really isn't that difficult to understand.
All the more reason to automate renewing of certificates.
I believe the intent here is:
* If you want an SSL certificate for, say, your printer
* And you don’t want to expose your printer’s port 80 to the public internet because you’re not stupid
* And you don’t want to put your DNS credentials onto your printer either, because again, you’re not stupid
* And you don’t want to pay for a certificate with a longer validity, because it’s a home printer, so you’re stitch with monthly cert rotations
* And you’ve embraced the reality that one can delegate SSL not just to CAs, but also to other third parties. Usually the likes of AWS & cloudflare - but why stop there?
Then this product is what you need!
Most people find the user experience of self-signed certificates much worse. The developer experience for local issuance isn't great, although mkcert does a really great job of smoothing the parts that can be smoothed[1].
I started but haven't yet completed a project to use mkcert on a home server, and get all devices in the house to trust it as a CA for things such as printers and "internal tools" for my family such as Jellyfin, etc.
This would probably be easier if I was organized enough to use at least minimal MDM features on the family's devices though, so I haven't actually completed this project yet.
Are there any printers that actually run acme where this is even a consideration?
> * If you want an SSL certificate for, say, your printer
Ummmm why does my printer need a certificate?
Well yes, you've just hit on why this is a rather niche product.
You get a handful of somewhat questionable benefits. If for some reason your guests are visiting your printer's administration page, they won't have to click through a scary warning page. If someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password.
But the main reason is some homelab enthusiasts are like bodybuilders at the gym - taking on tasks that seem Sisyphean to outsiders, for fun and to build their strength.
> someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password.
If they're persistently stealing traffic from my network then the printers administrative password is the least worrisome part.
> homelab enthusiasts are like bodybuilders at the gym
Self obsessed to the point of absurdity? There was a vulnerability a few years ago where you could embed an HP Printer Firmware update into the middle of a print file by taking advantage of some insane JCL commands. You can also embed JCL commands directly into a word document.
So these researchers created a word document that when printed updates your printers firmware with a hacked version allowing an advanced persistent threat to live inside your printer.
If your printer has no anti virus or no intrusion detection then putting an SSL certificate on there is entirely pointless.
If you're already thinking in the IPv6 mode of thought — where NAT / network-local addresses are irrelevant/obsolete, as long as there's a stateful firewall somewhere in front of your LAN devices, to treat all LAN devices as default-closed to incoming packets from outside the LAN's IPv6 network prefix...
...then (at least in theory!) there's no reason to not also give every one of those devices, with their public-routable IPv6 addresses, a stable public-rooted name — i.e. a DNS FQDN.
Mind you, none of the infrastructure to make this work exists.
For example, while DDNS exists, it really only exists to assign your gateway router itself a name — with the expectation being that you're using NAT, and then having your router port-forward any interior services to masquerade them as being services of the router.
A theoretical "DDNSv6", meanwhile, would instead expose your entire LAN as AAAA records under your DDNS suffix — much like how e.g. `tailscale share` exposes devices as device.yournetwork.ts.net. But using plain public-routed IPv6, rather than proprietary overlay routing.
The problem with this being that neither routers nor IoT devices have any way to assign DNS-like names to devices on your network. So where would these device names come from? (If it were me, I'd have the router observe mDNS announcements from these devices, and then suffix-replace `.local` in the mDNS name with the configured DDNS suffix to build AAAA records. But even then, some devices don't even do mDNS!)
And then, even if you do that, there's still nowhere for the TLS cert for your printer to live under this scheme. The printer itself has no concept of speaking TLS. (Why would it? It expects to only ever be local-segment routable, and for physical access to the network segment to be the sum total of its security mechanism.) To work around this, you'd need your gateway router to do L7 IPv6 routing (imagine if your router worked like Cloudflare DNS, where you could "orange cloud" your LAN devices) so that the router itself could 1. force itself as the default route for the device, even for LAN-to-LAN packets; and then 2. terminate the TLS connection if the device is being spoken to on port 443; but just act as a dumb passthrough otherwise.
> The problem with this being that neither routers nor IoT devices have any way to assign DNS-like names to devices on your network
Is this because an ipv6 network doesn't have DHCP which has the side effect of telling the router the hostname of the machine asking for an IP?
> still nowhere for the TLS cert for your printer to live under this scheme. The printer itself has no concept of speaking TLS. (Why would it? It expects to only ever be local-segment routable
one minor correction: modern (even 5-10 year old) printers do support TLS -- and they even try to push you to use it when they only have the built-in self-signed certificate. I've seen screens encouraging me to "click trust" etc. which seems idiotic to train anyone to do when the stakes of letting them admin the printer, over the LAN, over HTTP are so low. I'm so sure that a random rogue IOT device on my LAN is listening to that printer administration traffic, real high-value stuff there. Mind you that this is unrelated to whether a rogue LAN actor could sniff the actual documents being printed, since I don't think computers are typically set up to print with IPP over TLS, but use unencrypted protocols instead.
Anyway, with my HP printer, you can upload a cert and key file and that way it'll use a cert of your choice.
We take security very seriously, which is why we designed Relay to work so that we never have to see your encryption keys. If Let's Encrypt is working well enough for you, that's great, but we've also heard about rough edges that people struggle with so we are trying to help them out.
There's a scale beyond which the real challenge isn't issuing a certificate.
I see organisations with thousands of SSL certificates, and their struggle is real. Even reputable companies with huge teams have their certificates expire or served badly. Some serve expired certificates for years!
Plus, enterprise alternatives are extremely costly and rigid.