Name Constraints or separate sub-CAs: how should you scope an intermediate's authority?

Name Constraints or separate sub-CAs: how should you scope an intermediate's authority?

When you delegate issuance to an intermediate CA, how do you stop it from issuing for domains it should never touch? Two approaches bound the authority differently.

The Name Constraints extension (RFC 5280 §4.2.1.10) embeds permitted and excluded name subtrees directly into the intermediate certificate. A constrained sub-CA limited to .corp.example.com cryptographically cannot issue a trusted certificate outside that namespace — the path-validation algorithm rejects it. One intermediate, hard-scoped, enforced by every conforming client.

Issuing multiple separate sub-CAs instead relies on policy and operational discipline to keep each in its lane, with no cryptographic enforcement of scope. It offers flexibility but trusts process where Name Constraints trusts math.

The historical caveat: Name Constraints enforcement was patchy in older clients, which is why public CAs were slow to rely on it. In controlled internal environments where you know the clients, it is far more dependable.

— Use Name Constraints to cryptographically cage an internal sub-CA.
— Verify your client stack actually enforces the extension before relying on it.
— Reserve multiple sub-CAs for genuinely independent trust domains.

Further reading: RFC 5280 §4.2.1.10; RFC 9618 on constraint clarifications.

Bottom line: Name Constraints enforce scope in cryptography rather than policy — superior where clients honor it, which is most controlled internal fleets.