SSL errors: every browser code explained and fixed

The first useful question is not what the error means but who can fix it. Some errors are yours to resolve in seconds; most are the site owner's, and no amount of clicking will help you.

Find your code

Every browser shows a different code for the same underlying problem. Yours is on the error screen, usually below the message and sometimes behind an "advanced" or "details" control. If you cannot see one, start with what this screen is, which covers how to reveal the code in each browser.

The last column is the honest one. Six of these nine cannot occur when the certificate is issued and served by the same layer: there is no expiry for anyone to miss, no chain to assemble wrong, no name left uncertified, and no protocol set to fall behind. One is marked *partly* because the edge cannot answer for a broken origin or for a middlebox on the visitor's path, and a wrong clock on a visitor's own device is never the site's to fix. Claiming otherwise would be the kind of promise this page exists to argue against.

The pairs matter: ERR_CERT_COMMON_NAME_INVALID and SSL_ERROR_BAD_CERT_DOMAIN are the same fault seen through different browsers, so a fix described for one applies to the other.

The four things that actually go wrong

Behind every code in that table is one of four situations, and recognising which one you are looking at is most of the diagnosis.

• The certificate does not cover the name you asked for

  A certificate is issued for specific names, and a visit to a name not on the list fails even though the certificate is perfectly valid. The usual cause is www and the bare domain being treated as one name when they are two.

• The certificate is not trusted

  Either it was not issued by an authority the browser trusts, or the server did not send the intermediate certificates that connect it to one. The second is far more common and looks identical to the first from the outside.

• The certificate is out of date

  Expired, not yet valid, or revoked. The interesting case is the device: a clock set wrongly makes every valid certificate look expired, which is why this error sometimes appears on one machine and nowhere else.

• The connection failed before certificates were reached

  Protocol version mismatches, cipher mismatches, interception by antivirus or corporate proxies, and plain network problems. These produce the vaguest codes and need the most elimination.

If you are a visitor

Three checks resolve the errors a visitor can fix, and they take about a minute.

• Check your device clock

  If it is wrong, certificates appear expired or not yet valid everywhere at once. A site failing on your machine while working elsewhere points here first.

• Try a different network

  Public and corporate networks intercept connections, and interception is indistinguishable from an attack as far as your browser is concerned, which is the honest reason it complains.

• Try without extensions or antivirus interception

  Security software that inspects encrypted traffic is doing exactly what the warning describes, and some do it badly.

If none of those changes anything, the problem is at the site, and there is nothing further you can do from your side. Proceeding past the warning is possible in most browsers and it is a genuinely bad idea on any page where you would type anything.

If you own the site

The order that finds the cause fastest is fixed: check what certificate is actually being served, then whether it covers the name, then whether it is current, then whether the chain is complete.

That order matters because the last one is the most commonly missed. A certificate can be valid, current, and correctly named, and still fail for a large share of visitors because the server was configured without its intermediate certificates. Browsers that happen to have cached the intermediate see no problem, which is why "it works for me" is not evidence.

Each code's page covers its own causes in order of how often they occur, with the fixes separated by who applies them.

Why the browser refuses instead of warning

A question worth answering, because the strictness looks excessive until you consider the alternative.

An unverified connection is exactly the condition an interceptor needs. If browsers rendered the page with a small warning icon, the warning would be ignored the way most warnings are, and the protection would be worth nothing precisely when it mattered. Stopping is what makes the check real.

The same reasoning explains why there is no way to permanently silence these warnings for arbitrary sites, and why the option to continue is deliberately awkward. A check that can be waived in one click is a check that gets waived by habit.

It also explains why a certificate problem takes a site down completely rather than degrading it. There is no partial state between verified and unverified, so a forgotten renewal produces an outage, and that is the practical reason certificate maintenance deserves the attention it rarely gets until the first incident.

Errors that are not certificate problems

Two frequently-searched errors are not SSL faults and are not covered here, because treating them as such sends people down the wrong path.

ERR_TOO_MANY_REDIRECTS is a redirect loop. It often appears alongside a certificate change, which is why it feels related, and the cause is redirect configuration rather than anything cryptographic.

ERR_CONNECTION_CLOSED and its neighbours are network or hosting failures. The connection ended before anything about certificates was decided.

Fix certificates with Bridge SSL

Bridge SSL issues and renews certificates automatically, including the intermediate chain, which removes the two most common causes on this page: expiry that nobody noticed and an incomplete chain that fails for some visitors and not others. Certificates cover the names you publish, so www and the bare domain do not become two separate problems. See what the platform offers at Bridge CDN.

FAQ