I wish there was a way to just get a wildcard and use it to issue "sub certificates" of some sort. ie: *.internal.mycompany.com could be used to issue valid certs for git.internal.mycompany.com...
> The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located.
That is, you get a CA certificate signed by some trusted CA; that essentially makes you a CA; the nameConstraints section restricts it to a certain set of names, so the rest of us are okay w/ you being a CA as we know you can't issue for google.com. E.g., a nameConstraint of ".mycompany.com" allows you to issue under mycompany.com.
Sadly, and this is the key bit, AFAIK, this is completely unsupported by browsers¹ and CAs. So, it's not possible to get one, and AFAIK, even if you did, it wouldn't work. I really wish this was different, since it would make the whole certificate thing considerably easier for a lot of usecases, IMO, and is a more sensible way of doing things.
[1]: https://tools.ietf.org/html/rfc5280#section-4.2.1.10
¹I think Firefox might support them, but I think that might be it.
If you control a name constrained subCA for example.com, then new leaf certificates can appear under there at your whim, but there are a bunch of rules that need to be followed for leaf certificates, so how do those get enforced? The root CA is responsible for ensuring they are.
One option is you could say OK, they just don't. So then certificates under these constrained subCAs are _worse_ than the rest of the Web PKI, why should we trust these subCAs? Clearly browsers should forcibly distrust them in that case.
Another option is, the root CA has physical control and all issuance goes through them anyway. But if you do this (and a few outfits have done it) then there's no practical benefit to the constrained subCA existing at all. It's just extra baggage.
But that's not a huge obstacle, account based issuance exists today in the corporate space, some tech person proves control every so often and as long as they keep that up to date all other account users get certs whenever they want.
It's the other rules that we don't trust you to enforce once given your own subCA.
1. Lifetime is an easy example. Having checked you own example.com the maximum longevity for a leaf certificate is 825 days. A subCA that itself only lasts 825 days would be kind of annoying (you'd need to replace it say once per year, then swap all your issuance to the new one each time), so presumably you're going to want it to last longer, whereupon nothing prevents you using it to issue yourself leaf certs that last longer even though that's forbidden.
2. Key checks are another rule for lead certificates that the root CA is supposed to check but if you have physical control how can they?
If you ask Let's Encrypt for a certificate for your Debian weak key because you forgot that the archaic Debian system you were trying to certify has a broken OpenSSL install out of the box it will just refuse. That key is no good. But how can the root be sure you run such checks every time on your own subCA ?
3. Or how about compatibility. The trust stores and the Baseline Requirements both say only to issue specific types of certificates, e.g. no SHA1 for security reason, but also no SHA3 because their software doesn't grok that yet. Or equally No putting arbitrary EKUs in certificates without explaining why. Rules like this also can't be enforced on the subCA.
Regarding 1: that's interesting. I guess I figure that part of validation should be to check that the expiry of a cert is within the expiry of the issuing CA certificate. But if this is an issue… what prevents CAs from doing this today, and if it's just "good behavior", why not codify this in the validation rules? (That is, any certificate can't expiry after the expiry of the certificate above it in the chain?)
Regarding 2 & 3… is not saying "it's the responsibility of the domain owner" not sufficient? Issuing poor keys only hurts them (and perhaps those who want to communicate with them, which that might be an issue). (I agree that this isn't a great response, and it would be better for the world as a whole if we got these checked, but is it really our job to force domain owners to do this? Also, IDK if I really trust that major CAs are doing a good job of checking these sorts of things given all the other issues we see with them.)
SHA1 is going to be ignored by user agents soon (already?), so a subCA won't issue those solely b/c they won't work. What's wrong with a subCA adopting SHA3 sooner than major CAs? (Given how long the switch off of SHA1 took … that seems like a plus?)
Better then to reject this whole "Let's give subCAs to random people to save them some work" approach altogether.
Can you trust that major CAs are doing a good job? Well, if you suspect that they aren't all the data is there to go look for yourself, please report anything untoward that you find to m.d.s.policy and/or the issuer.
For the final point - the problem is compatibility. We do not want to create myriad non-interoperable systems, that's why "the Internet" won in the first place. If not for the grave security problems with SHA1 (demonstrated collision for a relatively affordable sum of money) we'd be using that forever, even though newer hashes are nicer.
SHA3 in particular might never go anywhere. Its design (a sponge not another Merkle–Damgård construction like MD4, MD5, SHA1 and SHA2) has appealing properties such as preventing length extension attacks, but you can get many similar benefits from things like SHA512/256 (run SHA-512 but throw away bits to keep only 256 of them).
> nameConstraints in a root cert
I'm talking about nameConstraints in a non-root certificate; IDK if this has an effect on how browsers would or would not validate it. My comment is simply "last time I tried it, it didn't work." It was a few years back, so perhaps I should try it again.
But yea maybe parent poster could consider scheme: git-internal.yourdomain.com.