Using Let's Encrypt for local network devices

[supersat]

I recently ran into a problem where I wanted to make a Chromecast app for my HDHomeRun tuner. However, the Chromecast requires apps to be served over TLS, and CORS doesn’t work from a TLS origin to a non-TLS origin. Theoretically the HDHomeRun could be updated to support CORS and TLS, but there’s still the issue of getting a certificate for it.

Basically, devices like the HDHomeRun are discovered by their IP address and connected to directly. Even if I could get a certificate for these devices, connecting by IP address would cause a name match failure.

Plex appears to have solved this issue by issuing wildcard certs for *.accountid.plex.direct. They then resolve A.B.C.D.accountid.plex.direct to A.B.C.D. However, they’ve partnered with a commercial CA to provide this service, so it’s not really feasible to use for non-Plex services.

I was looking into the possibility of creating something similar with Let’s Encrypt and came up with a proof-of-concept called tlsmy.net. The README on GitHub has more details, but essentially you prove ownership of a particular Let’s Encrypt account by signing a request with your account private key, and then tlsmy.net will create a TXT record for .acme-challenge.accountid.tlsmy.net with the DNS-01 validation token you received from Let’s Encrypt. In this case, accountid is a base36 hash of your Let’s Encrypt account public key.

It works, and there’s some proof-of-concept code on GitHub: https://github.com/supersat/tlsmy.net. But, is this a good idea? Is this abusing Let’s Encrypt? The Terms of Service seem to allow it, and the actual agreement is between the end user and Let’s Encrypt (not tlsmy.net). You are of course trusting that tlsmy.net doesn’t generate rogue certificates, although Certificate Transparency logs mitigate some of that concern.

The most obvious problem is the 50 certificates per eTLD+1 per week, which is presumably designed to encourage service providers to not create extraneous certificates when they have the private keys for their customers. However, in this case, I intentionally do not have the private key for the corresponding subdomain wildcard certificates. Is this a case where that limit can be increased?

Alternatively, I’d love to see Let’s Encrypt support something like this natively. Local network devices deserve TLS too.

[_az]

Integrating the account thumbprint into the domain seems like a pretty good solution.

Let's Encrypt in the past seems to have blocked domains that map directly to IP addresses (e.g. ec2-xxx-xxx-xxx-xxx.region.compute.amazonaws.com) because they can change ownership unexpectedly. But you seem to have addressed that in your design.

@supersat

Is this a case where that limit can be increased?

I think so. Consider also: https://publicsuffix.org

[rmbolger]

This is a neat idea. But I’m confused about how it solves the original problem of cert validation when connecting to devices via IP address.

Plex’s solution works because they control the client and can make sure it connects via a name (albeit an IP based name). But you don’t control the clients connecting to your HDHomeRun, right? So won’t they continue connecting via bare IP?

Also, if you weren’t aware already, there’s been some work on a draft spec for supporting IP identifiers in ACME. It’s definitely gonna be a while before (or if?) it’s finalized. But at least there’s progress on that front.
https://tools.ietf.org/html/draft-ietf-acme-ip-06

[schoen]

Thanks for sharing this. I’d be glad to hear @jsha’s opinion of this concept.

[jsha]

Thanks for sharing, @supersat! Your design seems fine and I don’t consider it to be abusing Let’s Encrypt. The approach you describe seems to be, for better or for worse, the current best available practice for using TLS with devices on a home network.

Also, if you weren’t aware already, there’s been some work on a draft spec for supporting IP identifiers in ACME.

FYI, certificates for IP addresses won’t address the home-network use case, because the relevant IP addresses are in private IP spaces, meaning they are not unique (and public CAs cannot issue for them).