NET::ERR_CERT_INVALID: Why Chrome Blocks the Site and How to Fix It

Chrome's certificate verifier maps most failures to a specific status: untrusted issuer, wrong hostname, bad dates, revocation, weak signature or key, missing Certificate Transparency, name-constraint violations. When the leaf certificate cannot be parsed, or the chain fails for a reason that has no dedicated status, the verifier sets a generic status and Chrome reports NET::ERR_CERT_INVALID (net error -207). net_error_list.h calls it "a certificate that is invalid" and adds: "This error is not recoverable."

That last line has two practical effects. When a certificate has several problems, Chrome reports the most serious one, and this code is checked first. And it belongs to the fatal group, together with ERR_CERT_REVOKED, so the warning page has no "Proceed" link at all. It is a TLS-layer certificate problem, not DNS, not HTTP, and not a cache issue.

Wrong extended key usage. If a certificate has an extendedKeyUsage extension, it must include serverAuth ("TLS Web Server Authentication") or anyExtendedKeyUsage. A client-authentication, S/MIME or code-signing certificate installed on a web server fails here. A certificate with no EKU extension at all is accepted.

Unknown critical extension. Internal CA templates sometimes add a custom extension and mark it critical. Chrome must reject a certificate with a critical extension it does not understand.

Malformed or broken chain certificates. A leaf the parser cannot read, or an intermediate without CA basic constraints, typically from home-made CA tooling. Two look-alikes have their own codes: a SHA-1 signature gives ERR_CERT_WEAK_SIGNATURE_ALGORITHM, and a keyUsage that does not fit the handshake gives ERR_SSL_KEY_USAGE_INCOMPATIBLE.

With a proxied Cloudflare record, visitors see Cloudflare's edge certificate, which is issued by a public CA in the standard format. ERR_CERT_INVALID on a proxied hostname therefore points at a custom certificate you uploaded, or at something between the visitor and Cloudflare. Without a CDN, check every TLS terminator in turn: nginx, HAProxy, a WAF, or a corporate inspection proxy that generates its own certificates.

Inspect the extensions of each certificate file you deploy, before it reaches the server:

openssl x509 -in /etc/nginx/ssl/example.com.crt -noout \
  -ext extendedKeyUsage,keyUsage,basicConstraints,subjectAltName
# want: X509v3 Extended Key Usage: TLS Web Server Authentication
#       X509v3 Basic Constraints: CA:FALSE (or absent)

If only one network shows the error, the inspection proxy on that network is producing the bad certificate, and the fix belongs to its administrators.

1. Save the certificate the server sends:

   openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
     | openssl x509 -outform PEM > leaf.pem

2. Read every extension with openssl x509 -in leaf.pem -noout -text. Look for an Extended Key Usage line without "TLS Web Server Authentication" and for any extension marked critical that is not one of the standard ones (basic constraints, key usage, EKU, SAN, name constraints).
3. Get Chrome's exact reason: open chrome://net-export, start logging, load the site, stop, and open the file in the NetLog viewer. The CERT_VERIFY_PROC_PATH_BUILT event lists the verifier's errors, for example "The extended key usage does not include server auth".
4. Reissue: a public CA issues certificates in the expected format, for example sudo certbot --nginx -d example.com -d www.example.com. For an internal PKI, fix the template: serverAuth EKU, SAN entries, no custom critical extensions, intermediates marked CA:TRUE.
5. Deploy, then sudo nginx -t && sudo systemctl reload nginx, and retest every node.

There is no bypass, by design. What you can do:

• Try another network, such as mobile data. If the site loads there, the network you were on (an office or school proxy) is re-signing traffic with defective certificates; report it to its IT team.
• Try another browser. If Firefox shows a specific code from the table above, pass it to the site owner: it names the defect.
• If antivirus software scans HTTPS, turn that feature off and retry; a broken interception certificate looks exactly like a broken server certificate.

Clearing the cache or cookies does nothing, since certificates are not stored in the HTTP cache. If the error appears on every network and every device, only the owner can fix it.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep "Verify return code"
# → Verify return code: 0 (ok)

curl -sv -o /dev/null https://example.com/ 2>&1 | grep "SSL certificate verify"
# → *  SSL certificate verify ok.

OpenSSL does not apply every Chrome rule, so finish with a load in Chrome itself. For an outside view of the served chain and its fields, use the enterno.io SSL checker.

• NET::ERR_CERT_AUTHORITY_INVALID
• NET::ERR_CERT_COMMON_NAME_INVALID
• NET::ERR_CERT_DATE_INVALID
• SEC_ERROR_UNKNOWN_CRITICAL_EXTENSION
• ERR_SSL_SERVER_CERT_BAD_FORMAT