SSL Certificate Errors (NET::ERR_CERT…): Causes and Fixes

When a browser blocks a site and throws a red NET::ERR_CERT…warning, the cause almost always boils down to one of five things: the certificate has expired, the intermediate chain is missing, the hostname you typed isn't in the certificate, the server and browser share no TLS version or cipher, or the certificate has been revoked or signed with a weak algorithm. Read the error code carefully and you can usually pinpoint the cause in seconds.

This guide walks each error as symptom → how to confirm → fix. If a code is cryptic, paste it into the SSL Error Message Decoderto get a plain-English explanation; to inspect the live certificate's expiry, chain, and SAN list, use the SSL Certificate Checker; and when a handshake negotiation looks like the problem, run the TLS Version Check.

1. Expired certificate or wrong system clock — NET::ERR_CERT_DATE_INVALID

Symptom:"Your connection is not private / the certificate has expired" withNET::ERR_CERT_DATE_INVALID. Either the certificate's validity window has ended, oryour own device clock is set to the wrong date and falsely judges a still-valid certificate as expired.

Confirm:First check that your device's date and time are correct. If only one site fails, the server certificate has genuinely lapsed — use the SSL Certificate Checker to look up the domain and see whether notAfteris in the past. If many sites break at once, it's your clock.

Fix:For the clock, simply enable automatic time (NTP). For an expired server certificate, reissue and install a new one; with Let's Encrypt, confirm that certbot renew auto-renewal (typically on a 60-day cycle) actually runs by checking the cron/timer logs. Setting a 30-day expiry alert is the most reliable safeguard.

2. Untrusted or missing intermediate chain — ERR_CERT_AUTHORITY_INVALID

Symptom: NET::ERR_CERT_AUTHORITY_INVALIDor "issuer is not trusted". The classic trap is a server that sends only the leaf certificate and omits theintermediate that bridges it to a trusted root.

Desktop Chrome often slips through using a cached intermediate, while mobile devices, Java, and some API clients fail — producing the maddening "but it works on my machine" situation. Self-signed certificates or a private CA that isn't in the OS trust store throw the same error.

Confirm: Run the SSL Certificate Checkerand check that the chain completes as "leaf → intermediate → root". If the chain stops after one link, the intermediate is missing.

Fix: Install the fullchain file your CA provided. In nginx pointssl_certificate at the combined leaf+intermediate file; in Apache useSSLCertificateChainFile(or fullchain on newer versions). For a private CA, distribute the root to every client's trust store.

3. Hostname not in the SAN — ERR_CERT_COMMON_NAME_INVALID

Symptom: NET::ERR_CERT_COMMON_NAME_INVALIDor "this certificate is for a different domain". It fires when the host you connected to is absent from the certificate'sSAN (Subject Alternative Name) list. Modern browsers ignore the legacy CN field and read only the SAN, so a certificate with a CN but an empty SAN always fails.

Typical cases: using a certificate for example.com on www.example.com (or vice versa), or using a wildcard *.example.com on a two-level subdomain likea.b.example.com. A wildcard covers only one level.

Confirm: Expand the SAN list with the SSL Certificate Checker and match the exact host in your address bar against it. If you serve both apex and www, both must appear.

Fix: Reissue the certificate with every required hostname in the SAN (e.g. bothexample.com and www.example.com), or get a wildcard if the scope is broad. Then set up consistent apex↔www redirects.

4. No common TLS version or cipher — ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Symptom: ERR_SSL_VERSION_OR_CIPHER_MISMATCH. The certificate is fine, but the handshake fails because the server and browser can't agree on a shared TLS version or cipher suite. Maybe the server offers only TLS 1.0/1.1 (which browsers now block), or it forces TLS 1.3 only and an old client can't keep up.

Confirm: Use the TLS Version Check to see which TLS versions the server accepts. If both TLS 1.2 and 1.3 negotiation fail, this is almost certainly the cause.

Fix: In your server config, enable TLS 1.2 and 1.3 and allow a set of safe cipher suites. nginx example: ssl_protocols TLSv1.2 TLSv1.3;. Drop 1.0/1.1 for security and keep cipher groups that modern clients can negotiate.

5. Revoked or weak signature — ERR_CERT_REVOKED / not trusted

Symptom: NET::ERR_CERT_REVOKED (the CA withdrew the certificate, e.g. after a key compromise), or rejection because of a weak signature algorithm such asSHA-1 or 1024-bit RSA. The latter shows up on old self-managed certificates.

Confirm: Revocation is checked via CRL/OCSP. Use the SSL Certificate Checkerto read the signature algorithm and key length and confirm it isn't SHA-1 or 1024-bit; if the error string is ambiguous, paste it into the SSL Error Message Decoder to tell revocation, expiry, and chain issues apart.

Fix: A revoked certificate can only be replaced by reissuing with a new key pair — never bypass it. For a weak signature, reissue with SHA-256 or stronger and RSA 2048-bit or ECDSA P-256.

Worked example: tracing one error end to end

Suppose NET::ERR_CERT_AUTHORITY_INVALID appears only on mobile while desktop works fine.

1. Paste the code into the SSL Error Message Decoder — it points to "issuer not trusted, usually a missing chain."
2. Run the SSL Certificate Checker: the chain is a single "leaf" link — the intermediate is missing. Desktop Chrome only passed thanks to a cached copy.
3. Replace the file with the CA's fullchain (nginx ssl_certificate fullchain.pem;) and reload the service.
4. Run the SSL Certificate Checker again and verify the chain now reads "leaf → intermediate → root." Mobile connects cleanly.

The table below compares all five causes at a glance.