Name Constraints (nameConstraints extension)

Name Constraints, defined in RFC 5280, contains permittedSubtrees and excludedSubtrees. A verifier applies them to every certificate below the constrained CA in the chain: each name in the subject and SAN must fall inside a permitted subtree and outside every excluded one. For DNS names, a constraint of example.com matches example.com itself and any subdomain such as api.example.com; IP constraints are written as an address and a mask.

Why it matters

Name constraints turn a CA into a technically limited one. An organization can operate a subordinate CA permitted to issue only for its own domains, or a private CA whose root, once installed on laptops, cannot be used to impersonate outside websites. That makes trusting a partner's or vendor's internal root far less risky. Support has historically been uneven across platforms and TLS libraries, so test the clients you care about before relying on it.

Example

nameConstraints = critical, permitted;DNS:example.com, permitted;IP:10.0.0.0/255.0.0.0

In an OpenSSL extension section, this limits a CA to example.com, its subdomains and the 10.0.0.0/8 network.

Common misconceptions

• Name constraints belong in leaf certificates. They only have meaning in CA certificates, where they restrict what is issued below.
• A constraint on example.com excludes its subdomains. For DNS names it covers the domain and every name under it.
• Name constraints stop the CA from signing other names. The CA can still sign anything; it is relying parties that reject out-of-scope certificates, so client support is what counts.