Browser errors
NET::ERR_CERT_INVALID: malformed or rule-breaking certificates
NET::ERR_CERT_INVALIDNET::ERR_CERT_INVALID means Chrome could parse the connection but found the certificate itself broken or in violation of its rules. It is not about the date, the name or the issuer; those have their own codes. It usually shows up with homemade certificates, internal CAs and HTTPS-intercepting software.
Is it the site or your device?
Usually it is a homemade or internal certificate; a normal result from an outside check points to interception on your device. Compare what the SSL checker sees with what your browser sees:
curl ssl.sh/example.com
- The checker flags the certificate too: the server's certificate is malformed. Only the owner can fix it.
- The checker shows a normal public certificate: something on your device or network is replacing it, typically antivirus HTTPS scanning, a corporate proxy, or an outdated interception product generating certificates Chrome no longer accepts. See antivirus HTTPS scanning.
Causes
1. Hand-built certificate with missing or wrong extensions
Scripts that generate certificates without a SAN, with CA:TRUE on a server certificate, or with contradictory key usage fields. Inspect it:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -text | sed -n '/X509v3 extensions/,/Signature Algorithm/p'
Look for Basic Constraints, Key Usage, Extended Key Usage and Subject Alternative Name.
2. Unknown critical extension or malformed encoding
An extension marked critical that Chrome does not understand, or DER encoding errors from a buggy tool, makes the certificate invalid. Regenerate it with a standard tool.
3. Key usage does not fit the connection
If key usage forbids the operation used in the handshake, Chrome may report this code or the more specific ERR_SSL_KEY_USAGE_INCOMPATIBLE.
4. Interception product generating broken certificates
Old versions of HTTPS-scanning tools may produce certificates that modern Chrome rejects. Update or disable the HTTPS scanning feature.
5. Platform rules for locally trusted certificates
Apple's rules for TLS certificates (SAN required, RSA keys of 2048 bits or more, SHA-2 signatures, serverAuth EKU) apply to Safari and to apps using Apple's verifier, and are a good baseline for any internal certificate.
What it looks like in each browser
| Browser | What you see |
|---|---|
| Chrome / Edge | "Your connection is not private" with NET::ERR_CERT_INVALID |
| Firefox | Varies: SEC_ERROR_BAD_DER, SEC_ERROR_INADEQUATE_KEY_USAGE or SEC_ERROR_UNKNOWN_CRITICAL_EXTENSION |
| Safari | "This Connection Is Not Private" with an invalid-certificate explanation |
How site owners fix it
A well-formed certificate, ideally from a public CA, fixes it.
1. Prefer a public certificate. Any ACME CA issues a well-formed certificate for free.
2. If you must issue internally, use a proper CA and these extensions for the server certificate:
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr \
-subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 200 \
-out server.crt -copy_extensions copy \
-extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=critical,digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth")
The -copy_extensions option needs OpenSSL 3.0 or later.
3. Decode the result with the certificate decoder and compare it to a public certificate, then re-test with curl ssl.sh/example.com.
FAQ
Can a public website get NET::ERR_CERT_INVALID?
Rarely, because public CAs lint certificates before issuing them. When a public site shows it, the cause is more often security software or a proxy replacing the certificate with a broken one. Compare with curl ssl.sh/example.com.
My self-signed certificate works in Firefox but Chrome says NET::ERR_CERT_INVALID. Why?
Chrome's certificate verifier is stricter about structure than some other clients. Regenerate the certificate with a SAN, basicConstraints=CA:FALSE, keyUsage=digitalSignature and extendedKeyUsage=serverAuth, signed by a separate CA certificate rather than reusing one certificate for both roles.
Is NET::ERR_CERT_INVALID a sign of attack?
Not necessarily, but you cannot tell from the browser alone. Do not enter credentials on a site showing it unless it is your own system and you know the certificate is homemade.