NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION Fix

Problem

Chrome refuses the site with NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION, and the usual advice — check the expiry, install the intermediate, trust the root — does nothing, because none of those is the problem. The chain is trusted. The name matches. The certificate isn’t expired. What’s wrong is more specific and more interesting: a certificate authority in the chain was told exactly which names it was allowed to sign for, and this certificate is for a name outside that list.

Symptoms

• Chrome/Edge shows net::ERR_CERT_NAME_CONSTRAINT_VIOLATION, often on an internal or corporate site rather than a public one.
• The certificate looks otherwise fine: valid dates, hostname in the SAN, chain building to a trusted root.
• It frequently appears (or newly appears) with a private/enterprise CA, sometimes right after a Chrome update.
• Other tools — older browsers, openssl, some non-Chromium clients — may accept the same cert, because they enforce constraints less strictly.

What This Error Actually Means

A CA certificate can carry a Name Constraints extension (RFC 5280 §4.2.1.10) that fences in what that CA — and everything below it in the tree — is permitted to issue. It has two halves: permittedSubtrees, the name spaces the CA may issue into, and excludedSubtrees, the ones it may not. At least one must be present, and an exclusion always wins over a permission. RFC 5280 requires conforming CAs to mark the extension critical, which is the whole point: a client that doesn’t understand it must refuse the certificate rather than quietly ignore the fence.

For DNS names the matching rule is left-label addition. A constraint of example.com permits example.com, www.example.com, and a.b.example.com — anything you get by adding labels on the left. It does not permit notexample.com, and it does not reach sideways into a different domain. So if a CA is constrained to corp.example.com and someone issues a certificate for example.net (or even example.com, one level up), that leaf is outside the permitted subtree, and a validating client rejects the chain.

This is why the diagnosis feels backwards at first. Every check people reach for — trust, expiry, hostname match — passes. The failure is one level up: the issuer’s authority, not the leaf’s validity. Constrained CAs exist for good reasons. The CA/Browser Forum’s Ballot 105 (2013) defined the “technically constrained subordinate CA” precisely so an organization could run its own issuing CA under a public root without a full audit — the trade being that such a sub-CA with the TLS server EKU must carry Name Constraints on dNSName, iPAddress, and DirectoryName. Internal PKIs constrain for a related reason: to guarantee their CA can never mint a trusted certificate for a domain they don’t own. The extension is a feature. This error is that feature doing its job on a certificate that shouldn’t have been issued.

Top 3 Causes

1. A constrained internal CA issued outside its permitted domains - The most common case with corporate PKI. The internal issuing CA (or the root above it) is constrained to, say, permittedSubtrees = corp.example.com, and someone requested a certificate for a host under example.io or a bare example.com. It builds and chains fine, but it’s outside the fence. The fix is to reissue the certificate for a name inside the permitted subtree, or, if the new domain is legitimately theirs, to widen the CA’s constraints and reissue the CA.
2. Chrome 112+ now enforces constraints on your imported root - If it broke after a browser update on an enterprise root you distribute, this is why. Chrome began honoring Name Constraints on user-imported/enterprise trust anchors in version 112 (April 2023); before that it only enforced constraints from intermediates. A root you constrained years ago as belt-and-suspenders is suddenly being enforced. The certificates were never actually compliant — reissue them within the permitted names, or re-cut the root with the correct constraints.
3. An IP-address SAN outside the permitted IP subtree - Constraints apply per name form, so a certificate with an iPAddress SAN is checked against the CA’s iPAddress permitted subtrees separately from its DNS constraints. A technically constrained sub-CA for TLS carries IP constraints too, and a cert with an IP SAN outside the allowed CIDR — or with an IP SAN when only DNS names were meant to be issued — trips the violation. The fix is to drop the offending IP SAN or bring the IP range into the CA’s constraints.

Diagnose with DechoNet

• SSL Check pulls the full certificate chain from outside your machine so you can read the leaf’s SANs and walk up to the CA that carries the Name Constraints. Comparing the leaf’s names against the constrained subtree is the whole diagnosis.
• HTTP Check confirms the server is up and responding, separating a certificate-policy rejection from an actual connectivity or redirect problem.

Resolution Checklist

• Read the chain, not just the leaf. Pull the certificate chain and identify which CA carries the Name Constraints extension and what its permittedSubtrees / excludedSubtrees are.
• Compare every name on the leaf — each dNSName SAN and any iPAddress SAN — against those subtrees. Find the specific name that falls outside permitted (or inside excluded).
• If the name should be allowed, reissue the leaf for a name inside the permitted subtree; if the whole namespace is legitimately yours, widen the CA’s constraints and reissue the CA (this touches every cert under it).
• If it began after a Chrome update on an internal root, treat it as Chrome 112+ enforcing root constraints that were always there — the reissue path is the same, no browser flag “fixes” it.
• Re-run the SSL check and confirm every leaf name now sits inside the CA’s permitted subtrees.

When to Escalate

• If the certificate is for a name your organization genuinely owns but sits outside the CA’s constraints, escalate to whoever runs the internal PKI: the CA’s Name Constraints need widening and the CA reissued, which is a controlled change, not a per-cert fix.
• If this is a publicly-trusted technically constrained sub-CA issuing outside its permitted names, escalate to the CA operator — that sub-CA is non-compliant with the constraints it committed to, which is a policy problem on their side.
• If you can’t find any Name Constraints in the chain yet Chrome still reports the violation, escalate with the full chain in hand: something is presenting a different intermediate than you expect (a cross-signed or misconfigured path), and the chain being served needs to be corrected.