SSL/TLS errors mean the browser couldn't establish a trusted encrypted connection — usually an expired certificate, a name mismatch, an untrusted issuer, or a protocol mismatch. Identify which from the exact error code, then fix it on the server (owners) or proceed cautiously (visitors).
What is an SSL/TLS error?
Every time your browser loads an https:// page, it does two things before showing you any content: it negotiates an encrypted channel with the server, and it checks that the server is who it claims to be. An SSL/TLS error is the browser refusing to continue because one of those two steps failed.
The connection is either not private (encryption couldn't be agreed) or not trustworthy (identity couldn't be verified). A modern browser would rather stop than silently hand your data to the wrong party.
The negotiation step is the SSL/TLS handshake: a short, structured exchange in which the client and server agree on a protocol version (today that should be TLS 1.2 or TLS 1.3), pick a cipher suite they both support, and the server presents its certificate. If the two sides share no common protocol or cipher, the handshake collapses before any page data moves. That is what you see as SSL handshake failed or, in Chrome, ERR_SSL_PROTOCOL_ERROR.
The trust step is certificate validation. The browser inspects the certificate the server sent and asks a series of yes/no questions: is it still within its validity window, does the name on it match the site I typed, was it issued by a Certificate Authority (CA) my device already trusts, and can I follow an unbroken chain from this certificate up to a trusted root? Any single "no" produces an error and an interstitial warning page.
Crucially, the encryption itself may be working perfectly. The browser blocks you because it cannot vouch for who is on the other end, and an encrypted conversation with an impostor is worth nothing.
Which SSL error am I seeing?
Browsers each phrase these warnings differently — Chrome shows a code like NET::ERR_CERT_DATE_INVALID, Firefox shows SEC_ERROR_EXPIRED_CERTIFICATE, Safari just says the connection isn't private — but they map to a small set of underlying causes. Find the string you're seeing in the table below, read the one-line meaning, and follow the link to the focused fix guide.
| Error string / code | What it means | Who usually sees it | Fix guide |
|---|---|---|---|
ERR_SSL_PROTOCOL_ERROR | Handshake failed before a page loaded — protocol or config mismatch. | Visitor & owner | ERR_SSL_PROTOCOL_ERROR |
| "Your connection is not private" | Chrome's umbrella warning page — the next line carries the real code. | Visitor | Your connection is not private |
| "Can't provide a secure connection" | Generic secure-connection failure, often handshake or cipher related. | Visitor | Site can't provide a secure connection |
NET::ERR_CERT_AUTHORITY_INVALID | Issuer is untrusted — self-signed, internal CA, or broken chain. | Visitor & owner | NET::ERR_CERT_AUTHORITY_INVALID |
NET::ERR_CERT_DATE_INVALID | Certificate is expired or not yet valid — or the device clock is wrong. | Visitor & owner | NET::ERR_CERT_DATE_INVALID |
| "SSL handshake failed" (HTTP 525 / 4xx) | Client and server couldn't agree on protocol, cipher, or cert. | Owner | SSL handshake failed |
| Expired certificate (server side) | The validity window lapsed; renew and reinstall the cert. | Owner | Fix an expired SSL certificate |
If you're not sure which code you have, run the hostname through a checker that reports the live certificate's issuer, names, and expiry — it removes the guesswork before you start changing server config.
What causes SSL/TLS errors?
Strip away the browser-specific wording and almost every SSL/TLS error traces back to one of five conditions. Knowing which one you have tells you whether the fix is a renewal, a reissue, a config change, or simply correcting a device clock.
1. Expired (or not-yet-valid) certificate
Certificates carry a hard start and end date, and browsers reject anything outside that window without exception. This is the single most common cause and shows up as NET::ERR_CERT_DATE_INVALID.
On the server, the fix is a renewal — see how to fix an expired certificate and the date-invalid walkthrough. A surprisingly large share of these are actually a wrong system clock on the visitor's own device.
2. Hostname mismatch
The name in the address bar must appear in the certificate's Subject Alternative Name list. Visit www.example.com with a cert issued only for example.com, and validation fails. This commonly surfaces inside the generic "your connection is not private" page. The fix is reissuing the certificate with every hostname the site actually serves.
3. Untrusted or self-signed issuer
If the certificate was signed by an authority the device doesn't recognize — a self-signed cert, an internal corporate CA, or a free cert whose root isn't in the trust store — you get NET::ERR_CERT_AUTHORITY_INVALID. Public sites should switch to a publicly-trusted CA; internal tools need their CA distributed to client devices. The authority-invalid guide covers both paths.
4. Broken or incomplete certificate chain
A valid leaf certificate still fails if the server doesn't send the intermediate certificates that link it to a trusted root. The certificate is fine in isolation, but the browser can't complete the chain, so it reports the issuer as untrusted — often the same ERR_CERT_AUTHORITY_INVALID. The fix is installing the full chain (leaf + intermediates) in the server's certificate bundle, also a common trigger behind a failed handshake.
5. Protocol or cipher mismatch
If the client and server share no common TLS version or cipher suite, the handshake never completes and you see ERR_SSL_PROTOCOL_ERROR or a "can't provide a secure connection" message. This appears after a browser drops legacy TLS 1.0/1.1 while a server still only offers those, or when the server's cipher list is too narrow. Enabling TLS 1.2/1.3 with a modern cipher suite resolves it.
Should you fix it or just get past it?
The same error means very different things depending on which side of the connection you're on. Visitors can't fix the server, so the question is whether it's safe to continue. Owners can fix it, so the question is what to change and in what order.
Visitors: decide whether it's safe
First, sanity-check your own device. A wrong clock or date produces date-invalid errors on every HTTPS site at once — if many sites break simultaneously, fix your system time before blaming anyone. If the error appears on only one site, the problem is almost certainly on their end.
- Confirm you typed the address correctly — a lookalike domain with a mismatch error can be a phishing attempt.
- On a page where you'll enter a password, payment details, or any personal data, do not click through the warning. There is no safe way to submit sensitive data over a connection the browser can't verify.
- For a low-stakes, read-only page you trust, an expired cert is lower-risk — but understand that bypassing means you're vouching for an identity the browser couldn't.
- Try another network. Captive Wi-Fi portals and intercepting proxies are a frequent cause of one-off SSL warnings.
Owners: diagnose in order
Work from the outside in. Read the exact error code, confirm the live certificate state, then change the smallest thing that fixes it. A reliable order:
- Inspect the live cert — issuer, every covered hostname, and the expiry date. This alone identifies expired, mismatch, and untrusted-issuer cases.
- Check the chain — verify intermediates are installed, not just the leaf certificate.
- Check protocol & ciphers — ensure TLS 1.2/1.3 are enabled and at least one modern cipher suite is offered.
- Reload after each change from a clean browser session so you're not reading a cached warning.
Not sure which check is failing? Point the checker at your hostname and read the issuer, names, and expiry back in seconds.
Run the free SSL checker →Why do these errors keep happening?
Expiry-driven errors aren't going away; they're becoming more frequent by design. In April 2025 the CA/Browser Forum passed ballot SC-081, which steadily shortens the maximum validity period of publicly-trusted TLS certificates. The cap drops in stages until it reaches just 47 days by 15 March 2029. At that point a certificate that isn't renewed roughly every six weeks will expire — meaning teams move from one or two renewals a year to around eight renewals per year, per certificate.
The industry was already struggling at the old cadence. According to AppViewX, up to 25% of TLS certificates are expired at any given time. Compress the validity window to 47 days and any process that depends on a human remembering to renew will fail far more often. Manual calendar reminders don't survive that pace — automated issuance and renewal (for example via ACME) plus continuous monitoring become the only sustainable approach.
For the formal definition of how browsers enforce HTTPS-only behaviour once a site opts in, see RFC 6797 (HTTP Strict Transport Security), the standard that lets a server tell browsers to refuse any insecure fallback.
That's why catching expiry before your visitors do matters more every year. A passive external full scan watches your live certificate from the outside — the same vantage point a browser uses — and flags issuers, names, and expiry dates while there's still time to renew, rather than after the warning page is already in front of customers.