A TLS certificate error is the browser's way of saying it could not verify that it is talking to the genuine server for the address you requested. The connection may still be encrypted, but the identity check failed, so the browser cannot promise there is no impostor in the middle. Each specific error has a distinct cause on the server side and a specific fix.
Certificate warnings are easy to dismiss and dangerous to ignore, because the one time the warning is real is the time it matters most. Knowing what each error means lets you tell a harmless staging misconfiguration from an active interception attempt.
The errors and what they mean
| Error | What the browser is saying | Usual cause |
|---|---|---|
| Expired / not yet valid | Outside the certificate's validity dates | Renewal lapsed or server clock wrong |
| Hostname mismatch | Certificate does not cover this exact name | Missing SAN, www vs apex, wildcard scope |
| Self-signed | No trusted CA vouches for this certificate | Internal or test certificate on a public host |
| Untrusted / incomplete chain | Cannot build a path to a trusted root | Missing intermediate certificate |
| Revoked | The CA has withdrawn this certificate | Key compromise or mis-issuance |
| Weak algorithm | Signed with an algorithm no longer trusted | Old SHA-1 certificate |
Expired certificates
The most common error, and the most avoidable. Certificates have a fixed lifetime, now capped at just over a year by the CA/Browser Forum, and public issuers such as Let's Encrypt issue 90-day certificates precisely to force automation. When renewal fails silently, the site keeps serving the old certificate until it lapses, and then every visitor hits a wall.
Occasionally an "expired or not yet valid" error is actually a wrong clock on the visitor's device, not a server problem. If one machine sees the error and others do not, check its date and time first. This is a genuinely common support case: a device whose clock has drifted, or reset to a default date after a dead battery, will reject certificates that are perfectly valid for everyone else, because validity is judged against the local clock. The tell is that the problem follows the device, not the site.
Expiry deserves respect precisely because it is so mundane. It does not require an attacker or a subtle bug; it just requires someone to forget. The higher-profile outages caused by lapsed certificates almost always trace back to a renewal that was manual, or automated but unmonitored, on a certificate no one remembered owning. Treat every certificate as something with an owner and an alarm, not as a task completed once at launch.
Hostname mismatch
A certificate lists the names it is valid for in its Subject Alternative Name (SAN) field. If you request www.example.com but the certificate only lists example.com, the browser refuses it. Common causes: an apex certificate that forgot the www variant, a wildcard *.example.com that does not cover the apex itself, or a shared host serving the wrong virtual host's certificate. The fix is a certificate whose SAN list includes every name you actually serve.
# Inspect the names on a live certificate:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -text | grep -A1 "Subject Alternative Name"Self-signed certificates
A self-signed certificate vouches for itself, with no CA in the chain. It provides encryption but no third-party identity proof, so browsers reject it on the public web. It is perfectly reasonable inside a closed lab or for an internal service where clients have been configured to trust it, but on a public site it is indistinguishable to a visitor from an attacker's forged certificate. The fix for anything public: obtain a free certificate from a trusted CA.
Untrusted or incomplete chain
This one confuses people because the certificate itself is fine. Browsers build a chain from your server's certificate up through one or more intermediate certificates to a trusted root. If the server sends only its own leaf certificate and omits the intermediate, some clients cannot complete the chain and report it as untrusted, often intermittently, since some browsers cache intermediates and others do not.
fullchain.pem). Our chain and hostname validation check catches a missing intermediate.Revoked and weak-algorithm certificates
A revoked certificate has been withdrawn by the CA, usually because its private key was exposed or it was mis-issued. Browsers check revocation through OCSP or CRLSets and will block a known-revoked certificate. A weak-algorithm error means the certificate was signed with SHA-1 or a short key; modern browsers distrust SHA-1 signatures entirely. The fix in both cases is reissuance with current parameters.
Revocation is worth a moment because its handling is imperfect and shapes real behaviour. Historically browsers "soft-failed" revocation checks, treating an unreachable revocation server as "assume valid," so a determined attacker could sometimes suppress the check. Modern browsers lean on pushed revocation data such as CRLSets and on OCSP stapling instead, which is more robust. The practical takeaway for a site operator is narrow but important: if your private key is ever exposed, revoke the certificate and rotate the key immediately, and do not assume revocation alone fully protects users whose browsers may not see it promptly.
Reading an error before you react to it
When you hit a certificate warning, resist the reflex to click through, and read what the browser is actually telling you. The error name distinguishes a boring problem from a dangerous one. "Expired" on a site that worked yesterday is almost certainly a lapsed renewal, annoying but not sinister. "Hostname mismatch" often means you reached the right server by the wrong name. But "untrusted issuer" on your bank's login page, over public Wi-Fi, is exactly the shape of an interception attempt, and it is the one moment the warning is doing its most important work. The same dialog covers both the trivial and the critical, which is why understanding the categories, rather than reflexively bypassing them, is the real skill.
When is it safe to proceed?
On a public site you did not set up, treat a certificate error as a stop sign, especially before entering a password or payment details. The whole point of the error is that the browser cannot rule out an impostor, and that is exactly the condition an attacker creates. The narrow exceptions are systems you administer yourself, where you already know why the certificate is untrusted, an internal tool with a self-signed certificate, a staging box, a device on your own network.
Diagnose and confirm
To see exactly which error a server triggers and why, run the SSL/TLS checker; it validates the chain, the hostname coverage and the expiry in one pass. The broader website scanner shows certificate health next to protocol and header findings. Certificate handling is one layer of transport security; the underlying protocol, handshake and cipher choices are in SSL and TLS explained, enforcement in HSTS explained, and the bigger picture in the website security hub. Because certificate warnings are a favourite cover for interception, they also connect directly to how to spot phishing.
A final operational habit ties the whole topic together: monitor certificates as infrastructure, not as a one-time setup task. The errors in this guide are almost all preventable in advance rather than diagnosed in a crisis. An expiry monitor warns you weeks before a certificate lapses. A synthetic check from outside your network catches a missing intermediate that your own cache hides. Certificate Transparency monitoring alerts you if a certificate is ever issued for your domain that you did not request, an early sign of a compromised registrar or CA account. None of this is exotic tooling; it is the difference between learning about a certificate problem from your monitoring at 2pm on a Tuesday and learning about it from angry users when the whole site goes dark. Treat every certificate as an asset with an owner, an expiry alarm and an automated renewal, and the dramatic outages in this guide become routine, boring maintenance, which is exactly what security infrastructure should be.
