Just keep your routers and printers in the DNS. Or someone, such as your printer/router vendor, can do it for you.

If you are talking about networks that are air gapped from the internet, you would have a problem anyway with the short letsencrypt expiration times, and you will in any case need to do all kinds of hoops that are bigger problems than installing a local CA or settling for a "insecure" browser warning.

(Also LAN doesn't automatically mean rfc1918 addresses for many people, and getting less so all the time with IPv6 deployment coverage)

Are you seriously proposing that I expose my printers to the public Internet just so that they can use HTTPS on a local LAN?

If I must choose between the possibility that an attacker with local access might snoop/change my printed documents, and a possibility that my printer will become part of the next botnet through some firmware exploit, I'll definitely choose the former.

Addressability != reachability. This is how the internet used to work before people got stockholm syndrome with NAT :)

Letsencrypt doesn't require you to run a public facing web server on that domain, you can use DNS challenge validation where you prove control by putting a TXT record in your domain.

  printer-level0.printers.coorp IN A 10.10.10.10

Not a problem in any sane DNS, not a problem for your issuer (who doesn't care about the IP) - though it could leak data outside. So to fix it, you could just solve the challenge in outside-facing DNS and only resolve the IP address if the request came from inside the corporate LAN.

Also, my school has so many IPs that they do give public IPv4 addresses to all machines, printers, etc. but block access with a firewall.

> Are you seriously proposing that I expose my printers to the public Internet

Adding a name->address mapping for a private address doesn't magically make the private address globally routable.

You being able to see that my.internal.web.server.domain.tld maps to 192.168.43.123 doesn't mean that you can see that web server from your location.

Even if it was actually a directly routable address rather then one sat behind NAT it wouldn't be accessibly unless I'd expressly added a rule for that in my firewall to override the default "no access from outside unless some other rule has stepped in" rule. And this isn't a DNS issue either: even without the name that address would still be exposed with a bad firewall setup.

> Parent comment was talking about routers and network printers. No CA (except for if you're your own CA) would provision a certificate for "192.168.0.1" or "hp-laserjet".

hp could get a cert for 15327c5ba80d1b8933.hp.com and make it resolve to 192.168.0.5 (your printer).

What if someone else uses 192.168.0.5 for their printer too? This just seems incredibly insecure, where I'll have to keep a public record of the private addresses of my devices. Welcome to the Fishbowl.

Yes, RFC1918 addresses are ambiguous, and generally they have this problem, independent of using DNS. You should use IPv6 if you can.

But now you are running TLS, so the address conflict would just yield a cert error. (If the other guy plugged his network or printer into yours, that is)

Yes, I'm running TLS behind my NAT, where unsecured traffic should be safe. Or should we be using VPN tunnels within our private networks?

And at the same time, I've introduced an internet connection dependency and a 3rd party dependency. What happens when they decide to stop updating that cert, to save money?

You shouldn't treat a SOHO or home network, NAT or not, as secure. There are good reasons why we don't trust the network. Getting compromised is not an "if", it's a "when".

But then what about when the printer’s IP address changes because it’s dynamic?

ddns?

Or use addresses like https://192-168-1-1.hp.net (https://192-168-43-123.hp.net, https://10-20-30-40.hp.net, and so on) and a wildcard cert. No harder to document than telling people to go to http://192.168.1.1.

Though they should be more careful than to use to top-level domain as they need to include the private key in the device unless they have the devices call out to have a new certificate generated, perhaps 192-168-1-1.internaldevices.hp.net and so forth.

It would be necessary to use a different private key on each device for it to be secure, so something like 192-168-1-1.internaldevices1489420.hp.net

DNS got fixed to handle dynamic updates in the early 2000's.