TLS certificates for home/office LAN devices (letsencrypt?) | Hacker News Reader

TLS certificates for home/office LAN devices (letsencrypt?)

2 pointsrogerbinns5 comments

Is there any solution at the moment for deploying arbitrary systems in a home/office LAN and giving them usable SSL/TLS certificates? They don't have deterministic names, let alone some sort of system administrator to do the work.

An example I have seen is how plex did it - https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ - but that solution would then have to be duplicated for each piece of hard/software.

I was hoping letsencrypt had a plan for this.

View on HN

I'm not aware of anything like that existing, but this would be a nice side-project.

The solution I'm thinking of - pretty much the same thing Plex is doing, but more generalized - would allow clients to register a DNS label under a generic domain (think: DynDNS) and then request certificates from Let's Encrypt for that label (or any sub-labels) using DNS-based verification. This would support something like ip.userid.example.com, which could then resolve to your router's IP (or any other LAN device).

Deployment could be completely automated behind the scenes. This could be hosted for free like various DynDNS services (possibly by Let's Encrypt), but vendors could also easily run a service like that on a custom domain for the branding effect.

You seem to mostly be thinking about external access. I'm more concerned about internal LAN access, eg a printer, fridge, hifi receiver. Plex's solution of a .direct DNS domain would be a great pattern since routers etc could resolve them without even having Internet connectivity (think netgear/linksys style boxes).

There would only be Internet access needed for the intial setup to get the certificate, plus each renewal.

There is already a .local domain used by ZeroConf so maybe all this could be glued together to work?

No, this solution would work with LAN devices and internal IPs as well, although there would be some extra requirements if it needs to work without internet connectivity¹.

Some things to keep in mind:

* Publicly trusted CAs are not allowed to issue certificates for internal IPs (private network space) or internal hostnames (anything that doesn't end with an ICANN domain).

* .direct is a regular TLD; I'm not aware of anything that would make routers resolve them without internet connectivity. Plex solves this by simply replying to a query for ip.user.plex.direct with "ip".

¹ If you need offline support, or if your DNS cache refuses to accept replies with private IPs (some do, but I think you'd be fine with most SOHO devices), you'll need to manually add those hostnames to your DNS resolver or host file, or alternatively configure your router to resolve hostnames from DHCP leases (many routers do this automatically) and use your "public" DNS label as the device's hostname.

I'd hope that some sort of DNS namespace could be carved out with appropriate rules followed by everyone.

The automatic resolution is an optimisation I am suggesting. If ip.whatever.domain always resolves to ip then your local network infrastructure can do that without requiring external Internet connectivity at the time of resolution. You shouldn't require Internet connectivity for internal access!

The problem is that you'll still need some kind of unique "domain space", i.e. you can't have just <ip>.vendor.direct (or whatever the TLD would be), because then multiple users could get a signed certificate for the same FQDN, which would allow interesting MitM scenarios (that was one of the main motivations behind the decision to forbid CAs from issuing certificates for internal names).

Anyway, I think that the public DNS solution + DHCP hostname mapping + manual DNS configuration as a last resort would be good enough for almost every scenario I can think of.

Reply on news.ycombinator.com