Path validation in X.509 asks a short question: is there a chain of signatures from this server certificate up to something in my trust store, with nothing expired or revoked along the way? Nothing in that question limits which names a given authority may vouch for. A CA in Amsterdam and a CA in Beijing have identical authority over your-bank.example, because authority in this system is global by construction.
Everything built on top of the web PKI over the last fifteen years has been an attempt to claw some of that back. Certificate Transparency makes misissuance visible after the fact. CAA records let a domain owner tell CAs to stay away, though the enforcement is on the CA's honour. Pinning lets a client refuse anything but a specific key. Name constraints work from the other end: they are carried inside the CA certificate itself, and they bind the verifier, not the issuer.
What the extension actually says
The nameConstraints extension is defined in RFC 5280 section 4.2.1.10. It appears only in CA certificates, and conforming CAs must mark it critical, which means a verifier that does not understand it has to reject the certificate rather than ignore the field.
It holds two lists. permittedSubtrees enumerates the name spaces this CA and everything below it may issue into. excludedSubtrees enumerates name spaces it may not, and exclusions win over permissions. Each entry is typed: a DNS name, an IP address range, an email address, a directory name, a URI.
For DNS names the matching rule is left-hand label addition. A constraint of example.com permits example.com and mail.example.com and a.b.example.com. It does not permit notexample.com, because that is not the original name with labels added to the left. IP constraints are expressed as an address with a mask. Email constraints can pin a full address, a host, or a domain.
During path validation the verifier carries a constraint set down the chain, intersecting it at each CA certificate. A subordinate cannot widen what its parent granted. The leaf's subject alternative names are then checked against whatever survived the intersection.
The rule that catches everyone
Here is the part that produces broken deployments. Constraints apply per name type, and only when that name type is present. RFC 5280 is explicit: if a certificate contains no name of a type that is constrained, the certificate is acceptable with respect to that constraint.
So a CA certificate that permits only corp.example.com under dNSName has said nothing whatsoever about IP addresses. A subordinate under it can issue a certificate whose only subject alternative name is 203.0.113.10, and that certificate validates. The constraint you thought you wrote was "this CA can only sign for our domain." The constraint you actually wrote was "if this CA signs for a DNS name, it must be under our domain."
Constrain the types you want to allow, and explicitly exclude the ones you do not. In practice that means an excludedSubtrees entry covering 0.0.0.0/0 and ::/0 when you have no permitted IP ranges, and a zero-length excluded dNSName when you want no DNS names at all. The CA/Browser Forum Baseline Requirements spell this out in their definition of a technically constrained subordinate CA, precisely because the naive version does not hold.
Why the Baseline Requirements care
In February 2012 it emerged that Trustwave, a publicly trusted CA, had issued a subordinate CA certificate to a corporate customer so that the customer could generate certificates on the fly and inspect employee TLS traffic. The key was in a hardware module and the arrangement was disclosed voluntarily, but the capability was general: that subordinate could mint a certificate for any name on the internet, and every browser on earth would have accepted it. Trustwave revoked it, root programs debated consequences, and the episode fed directly into how the rules were tightened.
The result is the technically constrained subordinate CA. A sub-CA that carries proper name constraints plus a restricted extended key usage is treated as a much smaller risk, and is exempt from some of the disclosure and audit machinery that an unconstrained sub-CA now attracts. The incentive runs the right way: constrain your intermediate and you carry less compliance weight, because you can do less damage.
The same problem shows up in corporate TLS interception. An enterprise that pushes its own root to every managed laptop has handed itself the ability to impersonate any site to any of those machines. Name-constraining that root to internal domains would remove most of the blast radius. Almost nobody does it.
Where this is worth your time
| Scenario | What name constraints buy you |
|---|---|
| Internal CA on developer machines | A stolen internal signing key can forge *.corp.example.com and nothing else. Without constraints it can forge your bank. |
| Cross-certification between organisations | You can trust a partner's PKI for the partner's namespace without importing their entire issuing authority. This is the original design use case and the US federal PKI has leaned on it for years. |
| Test and staging hierarchies | A test root that escapes into a production trust store does bounded damage. |
| Publicly trusted sub-CAs | Lighter audit obligations under the Baseline Requirements, and a real reduction in what a compromise means. |
| Client certificate CAs | Email and directory-name constraints bound which identities can be asserted, which matters for mutual TLS deployments. |
Support, and the cost of checking
Enforcement is broadly present now across the major verifiers, and that was not always so. For a long stretch, name constraints were something you could set with no confidence that a given client would act on them, which is a poor foundation for a security control. Anyone deploying this today should still test against the specific clients that matter to them rather than assuming.
There is also a lesson in what happened when the checking code got exercised. In November 2022, OpenSSL shipped fixes for CVE-2022-3602 and CVE-2022-3786, two buffer overflows in punycode decoding. The path to reach them ran through name constraint checking of an email address in a certificate, after chain signature verification. The initial announcement rated the first as critical and it was downgraded to high before release, but the structure of the problem is what matters: a feature that limits authority added attack surface to the parser, and the parser was written in C.
That is not an argument against the extension. It is an argument for the general principle that certificate parsing is a bad place for memory-unsafe code, which the industry has been slowly acting on.
Practical notes if you are deploying one
- Constraints go on the CA certificate, so they are set at issuance. Changing them means reissuing that CA certificate and redistributing it. Decide the namespace before you generate.
- Exclude the types you are not permitting. Otherwise the constraint is narrower than you think in exactly the way an attacker would enjoy.
- Remember the parent intersects. A subordinate can only narrow. If a chain seems to be failing for no reason, check what the layers above permitted.
- Test with the real verifiers. A constraint that one library enforces and another silently permits is a constraint that does not exist for half your users.
- Pair with extended key usage. Restricting a sub-CA to server authentication, and constraining its names, are complementary limits and the Baseline Requirements ask for both.
The broader point is about how the web PKI distributes power. Every trust decision a user makes is currently all-or-nothing: you either trust an authority for the entire namespace or you remove it from your store and break things. Name constraints are one of the few mechanisms in the standard that lets that decision be partial, and they are underused relative to how cheap they are. If you run any private CA at all, this is a short afternoon of work that meaningfully shrinks what a stolen key is worth.