What Is a Certificate Error? – Causes and How to Fix It
Learn what TLS certificate errors mean, the four checks a browser performs, what each failure indicates, and why bypassing them is dangerous.
A certificate error means the client could not verify that it is talking to the site it asked for. The connection may still be encrypted; what failed is proof of identity.
1. What the Client Checks
Four questions are asked of every certificate presented:
- Is it valid now? Not expired, not used before its start date.
- Does it match the hostname? The name requested must appear in the certificate.
- Does it chain to a trusted root? Every intermediate must be present and trusted.
- Has it been revoked? Checked where revocation information is available.
Any failure produces an error, and each one points at a different fix.
2. The Common Errors
| Error | Meaning | Usual cause |
|---|---|---|
| Expired | Validity period has passed | Renewal not automated, or automation broke |
| Name mismatch | Hostname not in the certificate | Missing subdomain, or wrong virtual host selected |
| Untrusted issuer | Chain does not reach a trusted root | Missing intermediate, or a self-signed certificate |
| Self-signed | Issued by itself | Development setup reached in production |
| Revoked | Explicitly invalidated | Key compromise or reissue |
| Clock skew | Certificate appears not-yet-valid | The client's own clock is wrong |
The clock case is worth remembering: an incorrect device time makes every certificate on the internet look invalid.
3. Diagnosing It
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
This prints the subject, issuer, and validity window. The -servername flag matters: without it, a server hosting several sites may present a different certificate than a browser would receive.
4. Fixing It as a Site Owner
- Automate renewal and monitor expiry independently of the automation.
- Serve the full chain, including intermediates. Browsers often paper over a missing intermediate; many API clients do not.
- Cover every hostname in use, including
wwwand any subdomains. - Check every entry point — the edge, the origin, and internal services can each have their own certificate.
5. Fixing It as a Client
- Verify the system clock first; skew explains a surprising share of cases.
- Update the trust store, since old systems lack newer roots.
- Check for TLS-inspecting software, which substitutes its own certificate and must have that certificate trusted.
- Confirm the hostname you requested matches what the certificate covers.
6. Why Not to Bypass Verification
Disabling verification removes the guarantee that you are talking to the intended server. Encryption without identity means an intermediary can terminate and re-encrypt without detection.
In automated clients this appears as a one-line flag, which makes it tempting and dangerous — it silently converts an authenticated connection into an unauthenticated one for every request thereafter. Where an internal certificate authority is in use, add its root to the trust store instead.
7. Real-World Examples
- A renewal cron failing quietly, with expiry discovered by users.
- A certificate covering
example.combut notwww.example.com. - An API client failing where browsers succeed, because an intermediate is missing.
- A device with a wrong clock reporting every site as insecure.
8. Summary
Certificate errors mean identity verification failed on validity, hostname, chain, or revocation. Each failure names its own fix, and the client's clock is worth checking before anything else.
Never disable verification to make an error disappear — trust the correct root instead, and fix the chain at the server.