Common SSL errors explained

When a certificate check fails, browsers block the page and show an interstitial — Chrome’s “Your connection is not private”, Firefox’s “Warning: Potential Security Risk Ahead”. The useful part is the error code underneath. Each code names a specific failed check, which tells you exactly where to look. This guide decodes the common ones, using Chrome’s NET::ERR_CERT_* names with Firefox and Safari equivalents where they differ.

One thing to establish first: whose problem is it? If you run the site, run it through our SSL checker — you will get the same verdict browsers reach, with the reason spelled out. If you are just visiting and other people can load the site fine, the cause may be local: a wrong system clock, an intercepting proxy, or stale state in your browser.

NET::ERR_CERT_DATE_INVALID

What it means: the current date is outside the certificate’s validity window — nearly always because the certificate has expired, occasionally because it is not valid yet.

If it is your site: renew the certificate with your CA or hosting provider and reinstall it. Then make renewal automatic so this never recurs — an ACME client such as Certbot, or your host’s managed certificates.

If you are a visitor: check your own clock first. A device with the wrong date fails this check on every site, because certificates appear expired (or not yet valid) relative to your clock. Firefox shows this as SEC_ERROR_EXPIRED_CERTIFICATE.

NET::ERR_CERT_COMMON_NAME_INVALID

What it means: the certificate is valid — but not for this name. The domain in the address bar does not appear in the certificate’s Subject Alternative Names. The name is historical: browsers no longer consult the Common Name field at all, only the SAN list.

Classic causes: a certificate covering www.example.com visited as example.com (or the reverse); a subdomain not covered by the certificate (remember a wildcard *.example.com covers one level only — not a.b.example.com, and not the bare apex); or many sites sharing one IP address where the wrong certificate is served. Firefox says SSL_ERROR_BAD_CERT_DOMAIN.

Fix: re-issue the certificate to include every name visitors use, or redirect stray names to a covered one at a covered host. See wildcard vs SAN certificates for how to cover several names cleanly.

NET::ERR_CERT_AUTHORITY_INVALID

What it means: the chain of signatures does not end at a root the browser trusts. Three very different situations produce it:

• A self-signed certificate — normal on test rigs and router admin pages, wrong on anything public. Replace it with a certificate from a real CA (Let’s Encrypt is free).
• An incomplete chain — the server sends its leaf certificate without the intermediates. Desktop browsers often patch the gap silently, so the giveaway is a site that works in Chrome but fails on phones, in curl, or for API clients. Install the “full chain” bundle your CA provides. Our checker reports exactly what the server sends.
• An interception proxy — corporate networks, antivirus products and captive portals re-encrypt traffic with their own CA. If every HTTPS site fails on one network and none fail elsewhere, this is why.

NET::ERR_CERT_REVOKED

What it means: the CA has withdrawn this certificate before its expiry date — typically because the private key was compromised or the certificate was mis-issued. This one should be respected, not bypassed. Site owners: issue a fresh certificate with a new key. If the revocation is a surprise, find out why before anything else — a leaked key means replacing it everywhere it was used.

NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

What it means: this one is not about the certificate at all — client and server could not agree on a protocol version or cipher suite. Usually the server only offers obsolete protocols (SSL 3.0, TLS 1.0/1.1, all removed from browsers in 2020), or supports nothing the client accepts. It also appears when a CDN serves a domain it has no certificate configuration for. Because this is protocol-level, the right diagnostic tool is tls.studio, which shows exactly which versions and ciphers the server negotiates. Background reading: SSL vs TLS.

ERR_SSL_PROTOCOL_ERROR

What it means: the TLS conversation itself broke down — the client received something that is not valid TLS. Common causes: a service that is not HTTPS at all listening on port 443, a misconfigured proxy or load balancer, or middleware mangling the traffic. Check that the server actually terminates TLS on 443 and that nothing between client and server is rewriting it.

Mixed content: the padlock with a warning

Sometimes the page loads but the browser flags it as “not fully secure”. That is mixed content: an HTTPS page pulling images or scripts over plain http://. The certificate is fine — the fix is updating those URLs to https:// (or protocol-relative references) in your HTML and CMS settings.

A quick triage routine

1. Read the code, not just the headline — it names the failed check.
2. Check from a second device or network — if the error vanishes, suspect the first device’s clock, proxy or antivirus.
3. Run the domain through the SSL checker — expiry, name coverage and chain completeness are checked and explained in one pass, with the raw detail in Tech mode.
4. Fix, reload, re-check. Certificate fixes take effect immediately; if the error persists, the old certificate is usually still being served from a cache, another server in the pool, or a CDN edge.

And a closing rule of thumb: never click through certificate warnings on sites where anything sensitive happens. The one time it is a real attack looks identical to the hundred times it is a lapsed renewal.