TLS and SSL Errors Explained (Every Browser, Every Code)
TLS and SSL errors look like a hundred different problems across a hundred different browsers and tools, but they collapse into six root causes: expired certificates, broken chains, hostname mismatches, untrusted issuers, cipher/protocol mismatches, and revocation. This page maps every browser's specific error code back to its root cause, with one openssl command to diagnose your own certificate and links to the full fix for each scenario.
TLS and SSL errors look like a hundred different problems. Chrome says NET::ERR_CERT_AUTHORITY_INVALID. Firefox says SEC_ERROR_UNKNOWN_ISSUER. Safari just says "This Connection Is Not Private." curl says SSL certificate problem: unable to get local issuer certificate. Different wording, different browsers, different tools - but underneath, they collapse into a small number of root causes.
This page is the map. Six root causes, what each one actually means, the exact error code or message each browser and tool uses for it, and a link to the full fix for whichever one you're facing.
The six root causes of every TLS/SSL error
1. Expired certificate
The certificate's notAfter date is in the past (or, less commonly, notBefore is in the future - the certificate isn't valid yet). The simplest cause and the easiest to fix: issue a new certificate. Full guide to fixing an expired certificate, or check exactly when your certificate expires before it becomes a live outage.
2. Broken or incomplete chain
The leaf certificate is valid, but the server isn't sending the intermediate certificate(s) that connect it to a trusted root. Some browsers (Chrome, via AIA chasing) tolerate this; others don't. Symptom: works in one browser, fails in another, with no other explanation. Chain validation pitfalls, explained.
3. Hostname mismatch
The hostname in the browser's address bar doesn't appear on the certificate's Subject Alternative Name (SAN) list. Common causes: a wildcard that doesn't cover a subdomain three levels deep, a SAN list truncated during a renewal, or SNI misconfiguration serving the wrong certificate for the requested hostname.
4. Untrusted issuer or distrusted root
The certificate chains to a Certificate Authority the browser doesn't trust - most often a self-signed certificate, an internal CA that hasn't been distributed to the client's trust store, or a public root that's been dropped from the browser's trust list entirely. That last case is a live, current issue: browsers periodically stop trusting older CA roots under routine root lifecycle policy, and a certificate that worked yesterday can fail today with nothing changed on your side. The real causes of NET::ERR_CERT_AUTHORITY_INVALID in 2026 covers this in depth, including the diagnostic commands to identify which root your certificate chains to.
5. Cipher or protocol mismatch
The server only offers TLS versions or cipher suites the browser refuses to negotiate - typically a server still configured for TLS 1.0/1.1 or deprecated ciphers that modern browsers have dropped. Which cipher suites are still running in production (and shouldn't be).
6. Revocation
The certificate was valid and correctly issued, but the Certificate Authority revoked it before its natural expiry - because of a key compromise, a CA compliance failure, or a root-program-mandated cleanup. This one is easy to miss because it doesn't change the certificate's dates; a script that only checks notAfter will report the certificate as fine while a browser checking revocation status rejects it. Certificate Revocation in 2026: CRL, OCSP, and what's actually changed covers the mechanics; your CA can revoke your certificate on short notice for reasons that have nothing to do with you covers a real 2026 case where it happened to tens of thousands of certificates at once.
Error codes by browser and tool
Same six causes, different vocabulary depending on what's showing you the error:
- Chrome, Brave, Edge, Opera (Chromium-based) -
NET::ERR_CERT_DATE_INVALID(expired),NET::ERR_CERT_COMMON_NAME_INVALID(hostname mismatch),NET::ERR_CERT_AUTHORITY_INVALID(untrusted issuer or broken chain),NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM(outdated signing algorithm),NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH(protocol/cipher),NET::ERR_CERT_REVOKED(revocation). Full breakdown: Chrome, Brave, Edge. - Firefox -
SEC_ERROR_EXPIRED_CERTIFICATE(expired),SSL_ERROR_BAD_CERT_DOMAIN(hostname mismatch),SEC_ERROR_UNKNOWN_ISSUER/SEC_ERROR_CA_CERT_INVALID(untrusted issuer / broken chain),SSL_ERROR_NO_CYPHER_OVERLAP(protocol/cipher),SEC_ERROR_REVOKED_CERTIFICATE(revocation). Firefox maintains its own CA trust store separate from the OS, so a certificate can pass in Firefox and fail elsewhere or vice versa. Full breakdown: Fix 'Warning: Potential Security Risk Ahead' in Firefox. - Safari (macOS and iOS) - no error codes in the UI, just plain-English messages: "has expired," "is invalid" (hostname or chain), "cannot verify the identity" (untrusted issuer). Safari adds two rules of its own - it rejects certificates issued for more than 397 days even if unexpired, and distrusts anything chaining to the legacy Symantec PKI. Full breakdown: Fix 'This Connection Is Not Private' in Safari.
- curl / command-line tools -
SSL certificate problem: certificate has expired,unable to get local issuer certificate(broken chain),certificate verify failed(generic trust failure, useopenssl s_clientfor detail),hostname mismatch.
Diagnose your own certificate in 30 seconds
One command narrows almost any TLS error to one of the six causes above. Replace example.com with the affected hostname:
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates -issuer -subject -ext subjectAltName,extendedKeyUsage
This prints the validity dates (cause 1), the issuer (cause 4), the subject and SANs (cause 3), and the EKUs (relevant to the CA-compliance edge case covered in the untrusted-issuer section above). Add -tls1_2 or -tls1_3 to a second run of the same command to isolate protocol/cipher issues (cause 5). For chain completeness, count the certificates in the -showcerts output - if it's just one, the intermediate isn't being sent.
Stop diagnosing errors after they've already cost you traffic
Every error on this page is one your customers experience before you do, unless something is watching continuously and externally - the same way a browser does, not just checking whether a file on disk has a future expiry date. Expired certificates, broken chains, hostname mismatches, distrusted roots, weak ciphers, and revocation all require a live handshake check to catch; a script that only reads notAfter misses five of the six causes on this page.
Catch every one of these before a customer does
TLS Radar runs full TLS handshake validation against every certificate in your inventory, continuously and externally - expiry, chain completeness, hostname coverage, issuer trust, cipher and protocol compliance, and revocation status, across every browser trust store. Free tier covers three domains.
Related reading
Frequently asked questions
- What causes a TLS or SSL error?
- Six root causes cover nearly every case: the certificate has expired, the server isn't sending the full certificate chain, the certificate doesn't cover the requested hostname, the certificate's issuer isn't trusted by the browser, the server's TLS version or cipher suite is too old, or the certificate has been revoked by its issuer before its natural expiry.
- Why does the same certificate work in one browser but not another?
- Different browsers maintain different trust stores and different tolerance for chain issues. Firefox uses its own CA trust store separate from the operating system. Chrome tolerates some missing intermediate certificates that other browsers reject. Safari enforces stricter validity-period and legacy-CA rules than Chrome or Firefox. The same certificate can pass in one and fail in another without anything on the server changing.
- How do I find out which TLS error I'm actually hitting?
- Run openssl s_client against the affected hostname and check the dates, issuer, subject alternative names, and extended key usage in the output. That single command identifies four of the six root causes; a second run forcing a specific TLS version isolates protocol/cipher mismatches, and counting certificates in the chain output reveals whether intermediates are missing.
- Can a certificate fail without expiring?
- Yes - five of the six root causes have nothing to do with the expiry date. A certificate can be revoked, chain to a newly-distrusted root, be missing intermediates, cover the wrong hostname, or be served over a deprecated TLS configuration, all while its notAfter date is safely in the future. Monitoring that only checks expiry misses all of these.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.