
TLS certificates for home/office LAN devices (letsencrypt?) - rogerbinns
Is there any solution at the moment for deploying arbitrary systems in a home&#x2F;office LAN and giving them usable SSL&#x2F;TLS certificates?  They don&#x27;t have deterministic names, let alone some sort of system administrator to do the work.<p>An example I have seen is how plex did it - https:&#x2F;&#x2F;blog.filippo.io&#x2F;how-plex-is-doing-https-for-all-its-users&#x2F; - but that solution would then have to be duplicated for each piece of hard&#x2F;software.<p>I was hoping letsencrypt had a plan for this.
======
pfg
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.

~~~
rogerbinns
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?

~~~
pfg
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.

~~~
rogerbinns
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!

~~~
pfg
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.

