Comment by infogulch
3 years ago
From that it looks like the main issue is regulatory requirements that force CAs to log all issued certificates via CT (certificate transparency) logs. Given that this is the very thing we're trying to avoid with a private CA ("CT" and "leaking internal hostnames" are functionally synonymous) we seem to be at an impasse at the level of base requirements.
Maybe an IP constraint that restricts certs to only be valid in private IP spaces (10.*, 192.168.1.*, etc)?
I wouldn't say that's even the main issue, but it _is_ probably one of the more difficult ones to solve assuming that just logging all certs publicly the same way every other CA does isn't an acceptable solution for you.
The bigger issue right now is this:
> under current BRs, a name constrained subordinate has to meet all the same requirements an unconstrained subordinate does, which means secured storage and audits
Basically, even a name constrained intermediate CA is subject to all the same regulatory requirements as a trusted root CA. From a regulatory compliance perspective it'd be pretty much equivalent to operating your own globally trusted root CA, with all the auditing and security requirements that go along with that. And if you ever screw up, Let's Encrypt, as the root CA your CA is chained to, would be held responsible for your mistakes as required by the current BRs.
Basically, it's not happening anytime soon without some serious changes to the Baseline Requirements and web PKI infrastructure.
Yeah the auditing, logging, and security requirements seem to be the main blockers.
But practically I don't see a difference between a name constrained CA with a 90 day life and a wildcard cert with a 90 day life from the perspective of the requirements listed above. There are only benefits, because now you can scope down each service to a cert that is only valid for that service.
You can still use wildcard certificates to avoid leaking the entirety of your private hostnames, while providing transparency around the "authority" portion of your domains.
First, that has it's own security drawbacks because now every service has access to a wildcard cert that is valid for any conceivable subdomain. Second, how is that better than an intermediate CA with a short life where the CA cert is CT logged? The cert path would still include that logged CA cert...
But then your constrained CA doesn't get you anything, you could not get from the parent CA. You could save your troubles as well.