How to Fix NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION in Google Chrome & Web Servers in Pakistan

In corporate enterprise environments, banking networks, and universities across Pakistan, network engineers and users frequently encounter a specialized Google Chrome security error:

Your connection is not private
Attackers might be trying to steal your information from portal.example.pk.
NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION

Unlike common validation errors like expired validity or unknown issuer authorities, NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION is triggered by a strict violation of X.509 RFC 5280 Name Constraints.

In enterprise Public Key Infrastructure (PKI) architectures, root Certificate Authorities often delegate issuing authority to Subordinate (Intermediate) CAs. To prevent a subordinate CA from going rogue and issuing valid certificates for unauthorized third-party domains (such as google.com or microsoft.com), the root CA embeds a Name Constraints extension restricting the subordinate CA to a specific DNS domain subtree (e.g. only .corp.example.pk).

If that subordinate CA subsequently signs a leaf certificate for a domain outside its permitted scope—or if a developer adds a Subject Alternative Name (SAN) that falls outside the allowed boundary—Chromium immediately terminates the connection.

In this guide, we unpack the Name Constraints extension with OpenSSL, identify the exact scope mismatch, and re-issue compliant enterprise certificates on bare-metal Dedicated Servers and Dedicated Servers in Pakistan.

---

1. How X.509 Name Constraints Work (RFC 5280)

The Name Constraints extension (id-ce-nameConstraints, OID 2.5.29.30) is applied exclusively to CA certificates. It defines two mutually enforceable subtrees:

+--------------------------------------------------------------+
|             Enterprise Root CA                               |
+------------------------------+-------------------------------+
                               |
                               v (Issues Subordinate CA)
+--------------------------------------------------------------+
|             Subordinate Issuing CA                           |
|  Name Constraints Extension:                                 |
|  - Permitted Subtrees: .corp.example.pk                      |
|  - Excluded Subtrees:  .internal.example.pk                  |
+------------------------------+-------------------------------+
                               |
                               v (Signs Leaf Certificate)
+--------------------------------------------------------------+
|             Leaf Certificate: portal.example.pk              |
|  SAN: portal.example.pk (VIOLATION! Not in .corp.example.pk) |
+--------------------------------------------------------------+
Result: Chrome blocks with NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION

1. permittedSubtrees: The certificate is only valid for names that fall within the listed namespaces. A constraint of .corp.example.pk permits app.corp.example.pk and db.corp.example.pk, but forbids portal.example.pk or example.pk.
2. excludedSubtrees: Explicitly forbids the subordinate CA from signing certificates matching those namespaces, even if permitted by a broader rule.

When Chrome’s certificate verifier traces the trust chain from the leaf certificate up to the root, it validates every SAN DNS entry and IP address against the Name Constraints of every intermediate CA in the path.

---

2. Inspecting the Intermediate CA with OpenSSL

To diagnose which intermediate CA is enforcing the constraint and identify its exact subtree boundaries:

# Connect and save the intermediate certificate chain
openssl s_client -connect portal.example.pk:443 -servername portal.example.pk -showcerts </dev/null 2>/dev/null > /tmp/chain.pem

Split the chain and inspect the intermediate CA certificate:

# Inspect X509v3 extensions for Name Constraints
openssl x509 -in /tmp/intermediate_ca.pem -noout -text | grep -A 10 "Name Constraints"

A typical restrictive intermediate output will appear as:

X509v3 Name Constraints: critical
    Permitted:
      DNS:.corp.example.pk
      DNS:.dev.example.pk

Next, inspect the Subject Alternative Names on your live leaf certificate:

openssl x509 -in /tmp/leaf_cert.pem -noout -text | grep -A 2 "Subject Alternative Name"

If your leaf certificate contains DNS:portal.example.pk (which lacks the .corp. or .dev. prefix), Chrome flags it as an illegal out-of-bounds certificate.

---

3. Resolving the Constraint Violation

Depending on your authority over the enterprise PKI, you have two remediation paths:

Method A: Re-issue the Leaf Certificate Within the Permitted Namespace

If the subordinate CA cannot be modified (common with partner CAs or enterprise managed PKI), update your internal DNS and re-issue the certificate using a fully qualified domain name (FQDN) that resides within the permitted subtree:

# /etc/ssl/req.cnf
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = portal.corp.example.pk

[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = portal.corp.example.pk
DNS.2 = www.portal.corp.example.pk

Re-sign the certificate using the subordinate CA. Because portal.corp.example.pk matches DNS:.corp.example.pk, Chrome will validate the chain successfully.

Method B: Expand Permitted Subtrees in the Subordinate CA

If you manage the enterprise Root CA (e.g. OpenSSL CA or Microsoft Active Directory Certificate Services AD CS), update the subordinate CA’s certificate extension template to permit the broader domain namespace:

In OpenSSL CA configuration (openssl.cnf):

[sub_ca_extensions]
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
# Broaden permitted domain to include top-level domain and subdomains
nameConstraints = critical, permitted;DNS:.example.pk, permitted;DNS:example.pk

Re-issue the subordinate CA certificate with the updated constraints and deploy the new intermediate bundle to your web servers.

---

4. Modernizing Web Server SSL Deployment

In Nginx or Apache, always ensure that your web server serves the correct intermediate bundle without mixing incompatible legacy intermediates:

server {
    listen 443 ssl http2;
    server_name portal.corp.example.pk;

    # Fullchain must contain the leaf and the updated subordinate CA
    ssl_certificate /etc/ssl/certs/portal.corp.example.pk.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/portal.corp.example.pk.key;

    ssl_protocols TLSv1.2 TLSv1.3;
}

Reload Nginx:

nginx -t && systemctl reload nginx

Compare this with other cryptographic X.509 validation errors in our guides on Fixing NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM and Fixing NET::ERR_CERT_INVALID in Chrome.

---