What actually lets a Certificate Authority delegate issuance for one domain without risking the whole Web?

What actually lets a Certificate Authority delegate issuance for one domain without risking the whole Web?

The mechanism is the Name Constraints extension (RFC 5280 §4.2.1.10), and it is one of the most underused safety tools in the WebPKI.

The core danger of the certificate hierarchy is that any publicly-trusted CA can, technically, sign a certificate for any domain. A subordinate (intermediate) CA delegated to a third party inherits that unrestricted power — which is how a single compromised intermediate becomes a global threat.

Name Constraints scope that power. Placed in a CA certificate, the extension's permittedSubtrees and excludedSubtrees limit which names any certificate beneath it may bear. An intermediate constrained to permittedSubtrees: example.com can only issue for example.com and its subdomains; a certificate it signs for victim.org fails path validation at the client, regardless of the intermediate's signature being valid.

The critical detail is the criticality flag. To be enforced reliably, Name Constraints should be marked critical, so a client that doesn't understand the extension rejects the certificate rather than ignoring the constraint. Historically, incomplete client support and IP-address-constraint bugs limited deployment, but support is now broad.

This is the technical foundation for safely giving an enterprise its own constrained intermediate without granting it the entire namespace.

Further reading: RFC 5280 §4.2.1.10; the Mozilla Root Store Policy on technically-constrained sub-CAs.

Bottom line: Name Constraints turns an all-powerful intermediate into one scoped to specific domains — enforced at path validation, ideally marked critical so unaware clients fail closed.