Idea for LAN local Let's Encrypt, what do you think?

Question

This is an attempt at a solution to the problem of "I have a LAN service or an IOT device, and it can't serve HTTPS because it isn't on the open internet to reach Let's Encrypt".It's becoming increasingly troublesome these days to run a service on insecure HTTP. Doubly so to run a service with a self signed certificate, which gets treated as a sign of evil intent by all browsers. Creating your own CA cert and installing it as a trust root is possible, but bothersome. It's implausible for non technical people to learn to do this.Servers on the open internet can use Let's Encrypt to prove that they control their site, and obtain a certificate. This isn't true if the service is on a LAN-local IP and not accessible from outside. For example, a device that puts itself on your Wi-Fi.New idea: suppose there is a service that exists on your LAN, perhaps normally living in your router the same way that DHCP does, and it exposes two operations:- get a CA cert: used by browsers accessing HTTPS sites when they are on the LAN, the CA cert is included among the trust roots for this one operation.- get a signed HTTPS cert: used by services in a similar way to Let's Encrypt to obtain a certificate that identifies them as a secure service on the LAN. Might either be open access (on a home Wi-Fi router) or whitelisted (in an office).Over to you HN, do you think this is a good idea?

thatha7777 · Accepted Answer

This will give a creepy feeling to many security experts, but here's my two cents:
The only issue with this scheme is that any device that trusts your "internal CA" can be MITM'd as easily as someone can use/abuse your "get a signed HTTPS cert" functionality.
Assuming your LAN is truly not connected to the internet in any form or way, it seems like the benefits outweigh the risks --- no connection to the internet, fewer chances to MITM to begin with...
As an additional security measure, you could use a PKIX name contraint [?] to restrict your CA to be trusted only for *.myinternal.lan, so even if your internal CA issued a cert for mail.google.com, it would be rejected by the cert chain verification. ([?]: not entirely sure this works everywhere)
Alternatively, if this is a limited internet scenario, and not a truly no uplink whatsoever, maybe you could get a wildcard LetsEncrypt cert, and share that across your IOT devices.

LinuxBender · Answer

Do you mean, have a shared signing cert that permits signing anything on the RFC1918 address space and using IP's as names? I think that has has been proposed a few times and shot down each time. Or do you mean something else? CA's won't create signing certs for random/fake/internal domain names. Similar question on serverfault [1] and security.stackexchange.com [2] and here is the Cab Forum's requirements on internal names [3].
For networks that are partially isolated, but have outbound DNS, one method (of data exfil) that may work would be if you could convince LetsEncrypt to have a DTLS API gateway so that certs could be registered/renewed over encrypted DNS. This won't help for fully isolated networks however, even if they agreed to make such a thing.
[1] - https://serverfault.com/questions/964119/enable-https-on-a-p...
[2] - https://security.stackexchange.com/questions/103524/lets-enc...
[3] - https://cabforum.org/internal-names/