Make no mistake Name Constraints are a wonderful idea. A quick look at the RFC, RFC5280, tells us :-
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.
i.e. All certificates issued by a CA with name constraints will conform to a certain naming standard such as x.hairybikers.com. If you try to issue certificates to x.hirsutebikers.com the CA will object.
On the face of it this is a marvellous idea and prevent the misuse of your trust chain for nefarious purposes. The reality is somewhat less shiny unfortunately. My current client insists on them.
Problem 1. OpenSSL
OpenSSL does not support Name Constraints properly until you reach version 1; which is less than a year old. This means that almost everybody that uses OpenSSL in their stack is non-compliant. This is pretty much everyone outside Microsoft. In the last year I’ve had systems from almost every tier 1 enterprise vendor fall in a heap. Networking, provisioning, HR, a lot of explaining, some anguish and only an RFC between me and my dignity.
Problem 2. Microsoft
Microsoft also get the standard wrong but in the other direction. Basically a Name Constraint say defined on the SubjectAltName rfc822Name will be applied to other name types in the subject alt name causing headaches. Microsoft in effect overdo the standard.
There is a registry fix outlined in the following document; search for protectedroots
Now unfortunately this is not available via GPO so to set it domain wide will require a custom ADM.
Problem 3. Its a whitelist or blacklist
This means that you need to know all the namespaces you are going to need from the outset. Any extras will require a change to the sub-ca template and a re-issunace of the issuing ca certificate. This could occur in a merger scenario.
In summary, before implementing ensure:-
1. You think through the Namepsaces you require.
2. Check the Microsoft issue out and whether you have the issue in your environment.
3. Have the backing of your managers to deal with non-compliant vendors using OpenSSL. Frequently they will need to be threatened with removal from the infrastructure solution. The size of your organisation and the premium they put on security will govern the feasibility of this approach.