SSL Certificate Errors: What Each One Means and How to Fix It

How to read an SSL error

During every HTTPS connection, the browser runs a fixed series of checks on the certificate the server presents: is it within its validity dates, does it cover the domain in the address bar, does it chain to a trusted root, has it been revoked, and can both sides agree on a TLS version and cipher. Each check that can fail has its own error code. The headline text ("Your connection is not private", "Warning: Potential Security Risk Ahead") is shared across all of them — the code is where the information is.

Safari shows the same failures with generic wording ("This Connection Is Not Private") and no code, which is why debugging from Chrome or Firefox is easier. Google documents the Chrome codes in its connection errors help page, and Mozilla maintains an equivalent reference for Firefox. The sections below take the checks one at a time.

Expired certificate: ERR_CERT_DATE_INVALID

Every certificate carries a notBefore and notAfter timestamp, and browsers enforce both to the second. One second past notAfter, the certificate is dead — there's no grace period, and the failure hits every visitor simultaneously. It is the single most common certificate error, and it's pure operations: someone, or some automation, didn't renew in time.

The fix is to renew the certificate — issue a new one for the same domains, install it together with its intermediate, and reload the web server. Reloading matters: servers read certificates at startup, so a renewed file on disk does nothing until nginx -s reload or its equivalent runs. If visitors still see the error after renewal, they're almost certainly hitting a node or CDN edge that's still holding the old certificate.

One important variant: if a visitor's system clock is wrong, the browser's date comparison fails even though the certificate is fine. Chrome detects obvious cases and shows "Your clock is ahead" or "Your clock is behind" instead. If a single user reports an expiry error that you can't reproduce, have them check their clock before you touch the server.

Name mismatch: ERR_CERT_COMMON_NAME_INVALID

A certificate is only valid for the names explicitly listed in its Subject Alternative Name (SAN) field. The browser compares the hostname in the address bar against that list — the matching rules are standardized in RFC 6125 — and fails the connection if nothing matches. Despite the error code's name, modern browsers ignore the legacy Common Name field entirely; only the SAN list counts.

The classic triggers:

• www vs bare domain — the certificate covers example.com but not www.example.com, or the reverse. They are separate names and both must be in the SAN list.
• Uncovered subdomains — a certificate for the main site doesn't cover app.example.com. A wildcard certificate covers one level of subdomains; a multi-domain certificate covers an explicit list across any domains.
• DNS pointed at the wrong server — a new domain or subdomain resolves to a server (or hosting default vhost) that serves some other site's certificate. The mismatch is real; the certificate just isn't yours.
• Wildcard depth — *.example.com matches one label only. It covers app.example.com but not api.app.example.com.

Diagnose it by reading the certificate the server actually sends: click the padlock → certificate details → Subject Alternative Name, or use the command in the diagnosis section below. The fix is always one of two things: reissue the certificate with the missing name added, or stop serving that hostname from this certificate.

Untrusted issuer: NET::ERR_CERT_AUTHORITY_INVALID

The browser builds a chain from the server's certificate up to a root CA it already trusts. This error means the chain didn't reach one. Three very different situations produce it, and they need very different fixes:

Protocol and cipher errors: ERR_SSL_PROTOCOL_ERROR

Not every HTTPS failure is about the certificate. ERR_SSL_PROTOCOL_ERROR means the TLS handshake itself broke down before certificate validation even mattered: the server answered with something that isn't valid TLS. Common causes, roughly in order of likelihood:

• Plain HTTP on port 443 — the site or a proxy in front of it is answering HTTPS requests with unencrypted HTTP, typically a misconfigured vhost, container port mapping, or CDN origin setting.
• Ancient protocol versions — browsers removed SSLv3, TLS 1.0 and TLS 1.1 support years ago. A server limited to those gets ERR_SSL_VERSION_OR_CIPHER_MISMATCH. The fix is enabling TLS 1.2 and TLS 1.3 in the server configuration.
• No shared cipher suites — an over-hardened or very old cipher list leaves the browser and server with no overlap (Firefox calls this SSL_ERROR_NO_CYPHER_OVERLAP). Reset to a modern, mainstream cipher configuration rather than hand-curating.
• Middleboxes mangling traffic — QUIC/HTTP3 oddities, broken TLS inspection, or a firewall rewriting packets. If curl -v from outside the network succeeds while a specific network fails, the network is the suspect.

Our SSL configuration guide covers choosing sane protocol and cipher settings for the major web servers.

Revoked certificate: ERR_CERT_REVOKED

Revocation means the CA has declared the certificate invalid before its expiry date — most often because the private key was exposed (committed to a repository, leaked in a breach) or because the CA discovered a validation or compliance problem and was required to revoke. Browsers learn about revocations through mechanisms like CRLs, browser-pushed revocation lists, and OCSP stapling.

There is no "undo" for revocation. The fix is reissuance: generate a new private key, create a fresh CSR, and install the replacement certificate. Reusing the old key after a key-compromise revocation defeats the entire point — assume the old key is public knowledge and retire it everywhere it was deployed.

The page loads, but the padlock is broken

A different family of problem: no interstitial, the page renders, but the browser shows "Not secure", a warning triangle, or strips the padlock. That's not a certificate failure at all — the certificate validated fine. It almost always means mixed content: the HTTPS page is loading images, scripts, or stylesheets over plain HTTP. The fix lives in your HTML and database, not your certificate, and we cover it step-by-step in the mixed content errors guide.

The other member of this family is the redirect-shaped problem: the site works over HTTPS but visitors arriving on plain HTTP are never sent there. A permanent 301 redirect to HTTPS plus an HSTS policy closes that gap.

When the visitor's machine is at fault

If an SSL checker says your site is clean but a specific user still sees errors, work through the client-side list:

• Wrong system clock — by far the most common. A clock months in the past or future makes every certificate look not-yet-valid or expired. Enable automatic time sync.
• Antivirus HTTPS scanning — security suites that inspect TLS swap your certificate for their own. When their local root isn't installed correctly, every site errors. Toggling the AV's "HTTPS scanning" feature confirms it in seconds.
• Outdated OS or browser — old devices miss newer root certificates and modern TLS versions. Notably, devices that haven't received OS updates for many years can fail on sites whose chains rely on newer roots.
• Captive portals — hotel and airport Wi-Fi intercepts the first HTTPS request to force a login page, which presents the portal's certificate instead of yours. Logging in to the portal resolves it.

Diagnosing from the command line

One OpenSSL command shows you the certificate your server actually serves, the chain it sends, and the negotiated protocol — which answers most of the questions in this article at once:

# Show served certificate, chain, and verification result
echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null | head -25

# Just the validity dates and the names it covers
echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null | \
  openssl x509 -noout -dates -subject -issuer \
  -ext subjectAltName

Read the output top-down: the Certificate chain block should list your certificate plus at least one intermediate (a single entry means a missing chain), the subjectAltName list must include the hostname you're testing, and notAfter must be in the future. The -servername flag matters on shared hosting: it sets SNI, and without it you may be inspecting the server's default certificate rather than your site's. The s_client documentation covers every flag, and our OpenSSL cheat sheet collects the inspection commands you'll actually reuse.

Prefer a browser? Our free SSL checker runs the same checks — chain completeness, name coverage, expiry, protocol support — and reports them in plain language.

Stopping the repeat offenders

Almost every error in this guide is preventable with three habits:

Frequently asked questions