"Your connection is not private": how to read SSL certificate errors

The browser is telling you it could not prove the server is who it claims to be. That is worth taking seriously, because the warning exists to catch exactly the kind of interception it is describing. But in practice, most of these warnings come from boring configuration mistakes rather than attacks.

The useful skill is reading the specific error code, because each one points at a completely different cause. "Certificate error" is not a diagnosis any more than "check engine" is.

What each error code actually means

Error	Cause	Who fixes it
ERR_CERT_DATE_INVALID	The certificate has expired, is not valid yet, or your device clock is wrong	Site owner, or you if the clock is off
ERR_CERT_AUTHORITY_INVALID	Signed by something your device does not trust: self signed, a private CA, or an interception proxy	Site owner, or your IT department
ERR_CERT_COMMON_NAME_INVALID	The certificate is valid but not for this hostname	Site owner
ERR_CERT_REVOKED	The issuer withdrew the certificate, often after a key compromise	Site owner, urgently
ERR_SSL_VERSION_OR_CIPHER_MISMATCH	The server only offers protocols or ciphers your browser has dropped	Site owner
ERR_CERT_WEAK_SIGNATURE_ALGORITHM	Signed with something obsolete like SHA-1	Site owner

Notice how many of them are not yours to fix. Knowing that early saves you from reinstalling a browser over someone else's expired certificate.

Check your clock first

If you are seeing certificate errors on multiple unrelated sites, stop and check the date and time on the device. This is the single most common cause of a sudden, everything is broken TLS failure, and it is trivially easy to confirm.

Certificate validation is time based. The certificate says "valid from this date until that date," and your device compares those against its own clock. If the clock is wrong by enough, every certificate on the internet looks either expired or not yet valid. A device whose battery died, a machine restored from an old backup, a Raspberry Pi with no real time clock, a phone that lost its time source: all of them produce a wave of certificate errors that look like a catastrophe.

An NTP Time Check queries a real time server and shows the offset between it and your device clock in milliseconds. A few hundred milliseconds is normal. Minutes is suspicious. Hours or days explains everything.

# How far has my clock drifted?
https://netdebug.app/open/ntp?target=time.apple.com&samples=5

Inspecting the certificate itself

Once the clock is ruled out, look at what the server is actually presenting. The TLS Certificate Inspector connects to the host and reports the things that matter:

• Validity window. Not just whether it expired, but how soon it will. A certificate with four days left is a problem you can fix before it becomes an outage.
• Subject Alternative Names. This is the list of hostnames the certificate is actually valid for. Modern browsers ignore the old Common Name field entirely and only check SANs.
• Issuer chain. Who signed it, and who signed them.
• Signature algorithm and key strength. Old or weak algorithms get rejected outright by current browsers.

Most name mismatch errors become obvious in one look. A certificate issued for example.com does not cover www.example.com unless www.example.com is listed as a SAN, and a wildcard for *.example.com covers www.example.com but not example.com itself, and not api.staging.example.com either. Wildcards match exactly one label. That detail catches people out constantly.

The missing intermediate problem

This one deserves special attention because it produces the most confusing symptom in the whole category: the site works in your browser and fails everywhere else.

Certificates are issued in a chain. A root authority that your device already trusts signs an intermediate, and the intermediate signs the certificate for the site. To validate it, a client needs the whole chain. Servers are supposed to send the intermediate along with the leaf certificate.

When the server forgets the intermediate, desktop browsers often paper over it, because they have seen that intermediate before and cached it, or they fetch it automatically. Mobile devices, command line tools, mobile apps and other servers generally do not. So the site looks fine to you and fails for a large slice of your users, which makes the bug reports sound impossible.

If your site works for you and fails for other people, check the chain the server actually sends. That is nearly always the answer.

If it is your site

1. Confirm which hostname is failing

   The apex, the www version, or a subdomain? Each needs coverage in the SAN list. Auto renewal frequently covers one and quietly drops another after a configuration change.

2. Check whether renewal actually happened

   Automated renewal is wonderful until it silently stops. The common causes are a validation path that broke when something else changed, a DNS record that moved, or a renewal hook that has been failing into a log nobody reads. Look at the certificate the server is serving right now rather than what the control panel claims.

3. Verify the chain

   Make sure the intermediate is being sent. This is the difference between "works on my laptop" and "works everywhere."

4. Reload the service, not just the certificate

   Web servers hold certificates in memory. Writing a new file on disk changes nothing until the process reloads. A surprising number of "renewal did not work" reports are actually "nobody reloaded nginx."

5. Check every hostname you own, not just the main one

   The certificate that expires and takes down a service is almost never the one on the homepage. It is the API endpoint, the staging server, the webhook receiver, the mail host. Run a check across all of them on a schedule rather than waiting for a user to tell you.

That last point is worth automating. Chain a TLS inspection across your hostnames into one run, trigger it weekly, and you will replace certificate outages with calendar reminders. Every result is timestamped in Run History, so you can see expiry dates marching toward you rather than discovering them on a Sunday morning.

When you should actually worry

Most certificate warnings are misconfiguration. A few are not, and these are the ones where you should close the tab rather than click through.

• A major site that should never have a broken certificate. A bank or a large provider does not accidentally serve an untrusted certificate. If your bank throws an authority error, something between you and them is intercepting the connection.
• An issuer you have never heard of, on public Wi-Fi. Interception proxies announce themselves this way. A corporate network with a managed device is one thing. A hotel or airport network is another.
• Errors on every HTTPS site at once, with a correct clock. Clock drift explains this benignly. If the clock is right and everything still fails, something is sitting in the path.
• A certificate whose issuer changed unexpectedly. Worth confirming through another network before trusting it.

The practical test is easy: try the same site from a different network, such as cellular data instead of Wi-Fi. If the certificate is fine there and broken here, the network you are on is the problem, and that is the one situation where the warning means exactly what it says.

The short version

Read the specific error code, because each one has a different cause and a different owner. If several sites break at once, check your clock before anything else. If it is your site, inspect what the server is actually serving rather than what your control panel says, and make sure the intermediate certificate is included. And if a major site suddenly presents an untrusted certificate on a network you do not control, do not click through.