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.
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.