▲ | nine_k 3 days ago | |||||||||||||||||||||||||||||||||||||||||||||||||
I wonder if a separate CA would be useful for non-public-internet TLS certificates. Imagine a certificate that won't expire for 25 years issued by it. Such a certificate should not be trusted for domain verification purposes, even though it should match the domain. Instead it should be trusted for encryption / stream integrity purposes. It should be accepted on IPs outside of publicly routable space, like 192.0.0/24, or link-local IPv6 addresses. It should be possible to issue it for TLDs like .local. It should result in a usual invalid certificate warning if served off a pubic internet address. In other words, it should be handled a bit like a self-signed certificate, only without the hassle of adding your handcrafted CA to every browser / OS. Of course it would only make sense if a major browser would trust this special CA in its browser by default. That is, Google is in a position to introduce it. I wonder if they may have any incentive though. (To say nothing of Apple.) | ||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | jabiko 3 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
But what would be the value of such a certificate over a self-signed one? For example, if the ACME Router Corp uses this special CA to issue a certificate for acmerouter.local and then preloads it on all of its routers, it will sooner or later be extracted by someone. So in a way, a certificate the device generates and self-signs would actually be better, since at least the private key stays on the device and isn’t shared. | ||||||||||||||||||||||||||||||||||||||||||||||||||
|