for routers there's a simple and easy workaround. Let's say your router answers on "router.lan". All they would have to do is redirect this name via the router's DNS resolver to, say, 192-168-0-1.company.com, which would be an officially-registered domain that resolves back to ... wait for it... 192.168.0.1!
If you control company.com you can run wildcard DNS for any amount of "private" IP addresses, complete with an official and valid trusted certificate. For an internal IP address. Problem solved.
(and no, this is not theoretical, there were appliances some 10+ years ago that did exactly that...)
Re:Why HTTP/3 is eating the world
by WorldMaker on Thursday October 05, 2023 @05:34PM
(#37784571)
Yeah, that is mostly what I was describing. There's some rough security benefit to using more transient A/AAAA records under a GUID or other pseudo-random DNS name than a DNS zone that just encodes common link local addresses. There are definite security benefits to a company using mycompanyrouters.com instead of their home company.com (XSS scripting attacks and the like). So some things have changed over 10+ years, but yes the basic principles at this point are pretty old and certainly working in practice.
Doing Let's Encrypt/ACME for random localnet web pages is getting easier all the time and anyone can use that wildcard domain loophole if they want to build their own secure bootstrap protocols for localnet. It would be great if the ACME protocol more directly supported it than through the wildcard domain name loopholes currently in use, and that may come with time/demand. I imagine there are a lot of hard security questions that would need to be answered before a generally available "localnet ACME" could be devised (obviously every router manufacturer is currently keeping their secure handshakes proprietary because they can't afford to leak those certificates to would be MITM attacks), but I'm sure a lot of smart minds exist to build it given enough time and priority.