I'm always annoyed by the fact that no spec exists for a `intermediate CA for a particular domain`. If it exists, multiple level wildcard pain disappears and Subject Alternative Names stuff is not needed.
> and Subject Alternative Names stuff is not needed.
Somebody already chimed in about name constraints, but I'm going to emphasise again that SANs are not an "alias" mechanism. SANs are how to use the Internet's names for things with the X.509 standard. The X.509 certificate is intended as part of the X.500 global directory system. Have you used the global directory system? No, because it was never built. And so X.509's names aren't appropriate for the Internet, which actually was built.
PKIX (RFC2459 and successors) documents how to use X.509 for the Internet, and it defines Subject Alternative Name for writing three popular names things have in the Internet, DNS names†, IP addresses‡ and email addresses.
Historically when Netscape invented SSL in the mid-1990s they abused the X.509 Common Name field to put a DNS name as text, having nowhere else to put it and billions of other more important problems to solve. But CN is arbitrary human readable text, not a great way to write DNS names. There have been way too many bugs as a result, and that's before IDNs existed. For a SAN dnsName there's deliberately exactly one correct way to write an IDN, but if you're abusing Common Name it's unclear what you should do.
So, after PKIX was standardised it was required to write SANs in all certificates. The old Common Name was grandfathered in, but all certificates in the Web PKI should use either SAN dnsName or ipAddress or both as appropriate.
Modern web browsers don't look anywhere else. Your Chrome or Firefox isn't trying to parse mysterious text elsewhere in the Subject to see if it might be an FQDN, it just reads the SANs and parses those, the rest is for humans only.
† Yes both kinds (PKIX uses A-labels here)
‡ Yes both kinds (IPv4 and IPv6)
X.509 Name Constraints extension is what you are looking for.
They are VERY expensive when ordered from public CA, but we use them at work for internal PKI.
When I was setting up internal PKI back in 2015, I wanted to limit the CA to be less dangerous. At the time name constraints did not work. At all.
It wasn't possible to create a CSR with the field in OpenSSL, because the config parser didn't know about the key. So I did what any self-respecting person would do: I created the CSR manually with low-level API, plugging in the OID directly. When I tried to sign that one, the openssl libs just blew up with BIO_read_XXX errors everywhere.
I then tried the same thing with golang's TLS stack. Trying to operate on a CSR with name constraints triggered a panic. So I gave up - no name constraints on internal CA.
Never got to try it out, but considering how the client libraries behaved on seeing the flag, it would have been amusing to see how different clients behaved when served with a certificate chain that ended up in name constrained CA.
Yes, they are. The extension should be marked as critical, so if the client does not understand it it should error out.
At least java, go, curl and all major browser support it.
I believe clients that don't support name constraints extension won't pass certificate chain verification should the root, intermediate or certificate itself have a name constraint defined.
Good question. I’m guessing that modern browsers such as Google Chrome and Firefox does. When it comes to agents such as wget, curl, mstsc.exe, etc, then I’m not so sure.
Somebody already chimed in about name constraints, but I'm going to emphasise again that SANs are not an "alias" mechanism. SANs are how to use the Internet's names for things with the X.509 standard. The X.509 certificate is intended as part of the X.500 global directory system. Have you used the global directory system? No, because it was never built. And so X.509's names aren't appropriate for the Internet, which actually was built.
PKIX (RFC2459 and successors) documents how to use X.509 for the Internet, and it defines Subject Alternative Name for writing three popular names things have in the Internet, DNS names†, IP addresses‡ and email addresses.
Historically when Netscape invented SSL in the mid-1990s they abused the X.509 Common Name field to put a DNS name as text, having nowhere else to put it and billions of other more important problems to solve. But CN is arbitrary human readable text, not a great way to write DNS names. There have been way too many bugs as a result, and that's before IDNs existed. For a SAN dnsName there's deliberately exactly one correct way to write an IDN, but if you're abusing Common Name it's unclear what you should do.
So, after PKIX was standardised it was required to write SANs in all certificates. The old Common Name was grandfathered in, but all certificates in the Web PKI should use either SAN dnsName or ipAddress or both as appropriate.
Modern web browsers don't look anywhere else. Your Chrome or Firefox isn't trying to parse mysterious text elsewhere in the Subject to see if it might be an FQDN, it just reads the SANs and parses those, the rest is for humans only.
† Yes both kinds (PKIX uses A-labels here) ‡ Yes both kinds (IPv4 and IPv6)