Show HN: Anchor Relay – A faster, easier way to get Let's Encrypt certificates

Sure! yet automation only solves one problem (until it doesn't). Inventory and control/accountability is still needed at scale, and automation doesn't provide it.

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].

[1]: https://github.com/FiloSottile/mkcert

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.

If you can't trust your network, you'll want encryption, regardless of devices on it.

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.

I definitely agree it's strictly better than plaintext. But the counter argument is that introducing bad encryption makes it less likely you'll ever end up with good encryption because the perceived delta between good and bad encryption isn't enough to make people invest the effort compared to fixing the more obviously bad situation of just plaintext.

I honestly don't know if I fully buy that argument, but there's something to be said for the idea that the problem with "better than nothing" is that it presupposes "nothing" is what you'd otherwise end up with and the crummy solution is the best you're going to get. I think your blog post highlights this point. Encrypting email even without validating certificates is better than not doing the encryption at all, but is giving people the security blanket of "at least we're doing something" slowing down the process of taking that last step?

We theoretically could, but those certificates would show up in CT logs. (For quick & easy monitoring, you can get an RSS feed for your domain on https://crt.sh/, but it's not the most reliable service.) It would be a reputation killer if we did that, just like it would be for your DNS provider or ISP.

Certificate transparency logs are likely the only realistic way, but you could make the same argument against your DNS provider. Trust has to start somewhere.

Whether or not something like this makes sense to you is probably a question of your personal threat model.