SSL warnings look alarming but usually mean one specific check failed. What each error code means, how to fix it, and the chain problem that breaks mobile visitors while your own browser shows a padlock.

A visitor emails to say your site is showing a security warning. You open it yourself, and everything loads perfectly. You ask a colleague, and it works for them too. Somewhere out there, a browser refuses to trust a certificate that looks perfectly fine from where you are sitting.

This happens constantly, and the explanation is almost always the same: browsers do not all check certificates the same way, and some of them repair faults silently that others refuse to overlook.

The error code is where to start. It is the one part of the warning screen that tells you something precise.

What the Warning Screen Does Not Tell You

Chrome's full-page interstitial says "Your connection is not private." Firefox says "Warning: Potential Security Risk Ahead." Safari says "This Connection Is Not Private." All three are describing a conclusion, not a cause.

The cause sits in a code underneath, often behind an "Advanced" link that most visitors never click. That code distinguishes between problems that are hours of work apart — a certificate that expired yesterday and a TLS configuration that no modern browser will negotiate with are both "not private," and they have nothing in common beyond the warning screen.

Below are the codes you will actually encounter, and what each one is really telling you.

NET::ERR_CERT_COMMON_NAME_INVALID

The certificate is valid and trusted. It simply does not cover the hostname being visited.

Browsers match the address against the certificate's Subject Alternative Name list. The older Common Name field, which the error is named after, is no longer used for matching at all — a certificate naming only example.com will be rejected at www.example.com even though the two obviously belong to the same site.

Three causes account for most of these. The certificate was issued without the www variant. The server did not match the request to a virtual host and handed out its default certificate instead. Or a CDN is in front of the site and has not been configured for this specific hostname.

Testing both the root domain and the www version separately shows which one the certificate actually covers. You can check what a certificate covers without waiting for a visitor to report it.

NET::ERR_CERT_AUTHORITY_INVALID

The browser cannot trace the certificate back to an authority in its root store. Firefox reports the same condition as SEC_ERROR_UNKNOWN_ISSUER, and for self-signed certificates specifically, as MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT.

This one has three causes that need completely different responses:

The certificate is self-signed. Normal on a development server, never acceptable in production. No browser will ever trust it, because there is no authority vouching for it.

The chain is incomplete. The server is sending its own certificate but not the intermediate certificate that links it to a trusted root. This is the most common of the three and the subject of the next section, because it is also the one that hides.

Something is intercepting the connection. Antivirus software and corporate proxies decrypt HTTPS traffic by presenting their own certificate in place of the real one. If the intercepting software installed its root certificate correctly, this works invisibly; if it did not, every HTTPS site produces this error.

The third case is distinguishable from the first two in seconds: if the certificate validates when checked from outside your network but fails on your machine, the problem is local.

The Error That Hides From You

The incomplete chain deserves its own section, because in eight years of auditing client sites, it is the certificate fault I have seen go unnoticed the longest — sometimes for months.

Here is why. When a server omits an intermediate certificate, most desktop browsers fetch the missing piece themselves and complete the chain quietly. No warning appears. The site works. The person who deployed the certificate sees a padlock and moves on.

Mobile browsers mostly do not do this. Older clients do not. Crawlers do not. Command-line tools certainly do not.

So the site is broken for a meaningful share of visitors while appearing perfect to the person responsible for it. The symptom that eventually surfaces is exactly the one described at the start of this article: reports of a warning that nobody on the team can reproduce.

With Let's Encrypt, this fault has a single overwhelming cause. The certificate directory contains both cert.pem and fullchain.pem, and the server configuration points at the first when it should point to the second. One word in one line of config, and the chain is incomplete for everyone whose browser will not paper over it.

NET::ERR_CERT_DATE_INVALID

The certificate is outside its validity window.

Before touching the server, check the clock on the machine showing the error. A device with the wrong date will reject perfectly valid certificates, and this accounts for a surprising share of single-machine reports. If one computer in an office sees the warning and the rest do not, the clock is the first thing to rule out.

If the certificate has genuinely expired, the renewal failed — not the certificate. Certificates issued today typically last ninety days and renew automatically, which means a renewal cron can break and then fail silently for weeks. Nothing alerts you until the certificate actually lapses, at which point every visitor sees a full-page warning simultaneously.

The practical consequence: the expiry date is a thing to monitor, not a thing to react to.

ERR_SSL_PROTOCOL_ERROR

The connection failed during the TLS handshake, before certificate validation ever began. The message is vague because the browser genuinely has very little to report — the two sides could not agree on how to talk, so nothing further happened.

Common causes include a server still offering only TLS 1.0 or 1.1, both of which current browsers refuse outright; something other than a TLS service listening on port 443; a misconfigured SNI setup, leaving the server unsure which certificate to present; or a middlebox interfering with the handshake.

The important point is that your certificate may be flawless. This error happens before anyone looks at it. If you are debugging and the certificate keeps checking out, that is why.

If the connection fails rather than warning, confirm the basics first: a ping test shows whether the server is reachable, and checking port 443 shows whether anything is listening for encrypted traffic at all.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The client and server share no TLS version or cipher suite they are both prepared to use.

In practice, this means the server is old. A configuration limited to TLS 1.0 or 1.1, or offering only deprecated ciphers such as RC4 or 3DES, will be refused by every current browser. Enabling TLS 1.2 and 1.3 with a modern cipher list resolves it.

The reverse — a server configured for TLS 1.3 only, refusing an older client — happens occasionally in tightly controlled environments, but it is rare.

NET::ERR_CERT_REVOKED

The certificate authority has revoked the certificate before its expiry date. This is uncommon and never accidental: it follows a key compromise, a mis-issuance, or the authority itself being distrusted.

There is no configuration fix. The certificate has to be replaced.

SSL certificate problem: unable to get local issuer certificate

This is curl's wording, and it surfaces in PHP, Python, and most tooling built on the same library. Developers hit it far more often than browser users, usually when an API call that works in a browser fails from a script.

It has two causes that need opposite fixes:

The server is sending an incomplete chain. A server-side problem affecting every client that does not fetch intermediates itself — which is most non-browser clients.

The machine making the request has an outdated or missing CA bundle. A local problem affecting only that machine.

Test from a different network before changing anything. If the chain validates elsewhere, update the local CA store and leave the server alone. If it fails everywhere, the server is the problem, and fullchain.pem is almost certainly the answer.

Deciding Whether It Is Your Machine or the Server

Most time lost to certificate errors is spent fixing the wrong end of the connection. The test is straightforward:

Check the certificate from outside your own network. If it validates externally but fails locally, the problem is on your machine — interception software, an outdated CA store, or a wrong clock. If it fails externally too, the server is misconfigured and every visitor is affected.

This single check separates "my laptop has a problem" from "my site is down for a third of its visitors," and the two deserve very different levels of urgency.

A Note on Clicking Through

Browsers let you proceed past most certificate warnings. On your own development server, with a self-signed certificate you created, that is reasonable.

On a public site, it is not. The warning means the browser could not confirm it is talking to who it thinks it is talking to, and proceeding sends your traffic onward regardless. If you are a visitor rather than the operator, the correct response is to leave and contact the site some other way.

Sites with an HSTS policy remove the option entirely — the browser refuses the connection with no way past it. This is deliberate, and it means a certificate fault on an HSTS site takes the site completely offline for visitors rather than merely warning them.

Frequently Asked Questions

Why does the error appear on one device but not others?

Three usual causes: that device's clock is wrong, it has interception software installed, or its CA store is outdated. All three are local. A certificate fault on the server affects everyone, not one machine.

Can I fix a certificate error as a visitor?

Not on someone else's site. If it affects every site you visit, the cause is on your machine — check the clock first, then any antivirus that inspects HTTPS traffic.

I renewed the certificate, but the error persists. Why?

Usually the server is still serving the old file. Certificate renewal writes new files; the web server keeps the old ones in memory until it is reloaded. A reload is required, and on load-balanced setups, every node needs it.

Does clearing the browser cache fix certificate errors?

Rarely. Certificates are not cached the way pages are. The exception is a cached HSTS policy or a cached redirect, which can make a fixed site appear still broken on your own machine while working everywhere else.

Why does the warning appear on some pages but not others?

The certificate covers a hostname, not individual pages, so this usually means the pages are on different subdomains. A certificate covering the root domain will not cover shop.example.com unless that name was included explicitly.

The padlock is showing, but the site says "not secure" — which is right?

Both. The certificate is valid, but the page is loading at least one resource over plain HTTP. That is mixed content: a page-level problem, not a certificate problem. The browser console names the offending resource.

The Short Version

The error code is the useful part of a certificate warning, and each one points somewhere specific. COMMON_NAME_INVALID means the hostname is not covered. AUTHORITY_INVALID usually means an incomplete chain. DATE_INVALID often means a wrong clock rather than an expired certificate. ERR_SSL_PROTOCOL_ERROR means the handshake failed before the certificate mattered at all.

Before changing anything on the server, check the certificate from outside your own network. Half of all certificate errors turn out to be local, and fixing a server that was never broken is the most expensive way to spend an afternoon.

Written by Baleeghuddin Shaikh, SEO consultant with 8 years of experience in technical SEO and site diagnostics.