SSL/TLS Errors: Why They Break Websites and How to Fix Them

TL;DR

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are the cryptographic protocols that turn http:// into https://. SSL is the older name; TLS replaced it years ago, but everyone still calls it “SSL” colloquially. The two terms refer to the same family of protocols.

When your browser shows a warning like “Your connection is not private” or “NET::ERR_CERT_DATE_INVALID”, that’s a TLS handshake failure. The browser is refusing to load the page because it can’t verify the server’s identity. Most TLS errors fall into one of five categories — and most are 5-30 minute fixes once an operator notices.

If you’re a visitor: do not click through TLS warnings unless you’re absolutely sure what you’re doing. They exist to protect you from man-in-the-middle attacks.

What a TLS handshake actually does

When you visit https://example.com, before any HTTP request goes out, your browser and the server perform a handshake:

1. Browser:   "Hi server, here are the TLS protocol versions and cipher
               suites I support."

2. Server:    "Let's use TLS 1.3 with this cipher. Here's my certificate."
              (Sends the cert chain: server cert → intermediate → root)

3. Browser:   Validates the certificate:
              ✓ Is it within its validity period?
              ✓ Does it match the hostname I'm visiting?
              ✓ Is it signed by a trusted certificate authority?
              ✓ Has it been revoked (CRL/OCSP)?
              ✓ Does it support the protocols and ciphers I want?

4. Browser:   "OK, I trust you. Here's a key for our session."

5. Server:    "Got it. Encrypted channel is open."

6. Browser:   Now sends the actual HTTP request, encrypted.

Any failure at step 3 results in a TLS error and the browser refuses to proceed. The request never reaches the application layer at all.

The five most common TLS errors

1. Certificate expired

Every TLS certificate has a validity period — typically 90 days (Let’s Encrypt) or 1 year (commercial CAs). When it expires, browsers refuse to trust it. Browser shows: “NET::ERR_CERT_DATE_INVALID” or “Your connection is not private — the certificate expired N days ago”.

Cause: auto-renewal failed silently, monitoring didn’t catch it, the operator was on vacation. This is the single most common TLS failure and is responsible for hundreds of high-profile outages every year.

Fix as operator: renew the cert immediately. Set up monitoring that alerts at 30, 14, 7, and 1 days before expiry. Use certbot or your provider’s auto-renewal. Verify renewals actually succeed — a renewal that ran but didn’t deploy the new cert is just as bad as no renewal.

Workaround as user: none safe. Don’t bypass.

2. Hostname mismatch

The certificate is valid, but it’s for a different hostname. Common when a site has a cert for example.com but you’re visiting www.example.com, or vice versa, and the cert doesn’t include both names. Browser shows: “NET::ERR_CERT_COMMON_NAME_INVALID” or “The certificate is for a different domain”.

Cause: the operator generated a cert without a Subject Alternative Name (SAN) covering all the hostnames the site uses, or a wildcard cert is being used in a context it doesn’t cover.

Fix as operator: issue a new cert with all the relevant hostnames in the SAN. Use a wildcard (*.example.com) if you have many subdomains. Make sure your CDN configuration uses the right cert per hostname.

Workaround as user: try the alternate hostname. If www.example.com fails, try example.com directly.

3. Untrusted certificate authority

The cert was signed by a CA your browser doesn’t trust. This usually means it was self-signed (for testing) or signed by a CA that’s been removed from browser trust stores. Browser shows: “NET::ERR_CERT_AUTHORITY_INVALID” or “Issuer is unknown”.

Cause for production sites: rare and usually catastrophic — a CA was distrusted by browsers (this happened to Symantec/DigiCert in 2017-2018, GeoTrust before that). For internal sites, it’s normal — corporate networks use their own CA.

Fix as operator: issue from a trusted CA (Let’s Encrypt, DigiCert, Sectigo, Cloudflare’s CA). Verify the chain is complete (server cert + intermediate cert) — many “untrusted” errors are actually missing-intermediate errors.

Workaround as user: if it’s an internal site you know about, install your organization’s CA cert. For public sites, do not bypass.

4. Certificate chain incomplete

The site’s cert is fine, but the server isn’t sending the intermediate cert that connects the site cert to the trusted root. Some browsers (Chrome on Windows) silently fetch the missing cert; others (Firefox, mobile browsers) fail the handshake. Browser shows: varies — sometimes “untrusted CA”, sometimes works on desktop but not mobile.

Cause: server configuration omits the chain. The fix file usually combines the leaf and intermediate into a single bundle, but the operator only deployed the leaf.

Fix as operator: update the server’s cert config to include the full chain. Test with ssllabs.com/ssltest — it’ll flag missing intermediates explicitly.

Workaround as user: use a different browser. Safari/Chrome usually work where Firefox fails.

5. Protocol or cipher mismatch

The server only supports older TLS versions (1.0, 1.1) that modern browsers no longer accept; or it only supports newer ones (TLS 1.3) that older clients can’t speak. Browser shows: “NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH” or “Cannot make secure connection”.

Cause for new servers: misconfigured to be too restrictive, refusing TLS 1.2 connections.

Cause for old servers: ancient hardware that hasn’t been updated and only supports protocols modern browsers refuse to use.

Fix as operator: support TLS 1.2 and TLS 1.3. Disable SSL 3.0, TLS 1.0, and TLS 1.1. Cloudflare, Let’s Encrypt, and most modern web servers default to this configuration; the issue is usually a stale config.

Workaround as user: none safe. The browser is correctly refusing to use insecure protocols.

Less common but high-impact TLS failures

Certificate Revocation

A cert was revoked by the CA before its expiration date — usually because the private key was compromised. Browsers check revocation via OCSP or CRL and refuse the cert if it’s listed. Browser shows: “NET::ERR_CERT_REVOKED”.

OCSP soft-fail / hard-fail

The browser tries to check whether the cert is revoked by querying the CA’s OCSP server. If OCSP is unreachable, browsers either hard-fail (refuse the connection) or soft-fail (warn but allow). Configuration depends on the browser and platform.

HSTS preload incompatibility

The site is on the HSTS preload list, meaning browsers refuse to connect over plain HTTP. If TLS is broken, the user can’t even fall back to HTTP to see what’s going on — they get a hard error with no bypass option.

Certificate Transparency (CT) logging issues

Modern browsers require certs to appear in public CT logs. If the cert was issued without CT logging, it’s rejected. Rare in 2026 but possible with self-rolled CAs or non-compliant providers.

How to diagnose TLS errors as a visitor

1. Read the exact error code. “NET::ERR_CERT_DATE_INVALID” is fundamentally different from “NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH”. The error code tells you the cause.
2. Check the date on your computer. If your system clock is wildly wrong, every cert will appear expired or not-yet-valid. This is a surprisingly common cause of TLS errors on devices that haven’t been used in a while.
3. Try a different browser. Chrome, Firefox, and Safari validate certificates with subtly different rules. Sometimes one browser surfaces a problem the others tolerate.
4. Try a different network. Some corporate networks intercept TLS for inspection (and substitute their own cert). If a site fails on the corporate VPN but works on cellular, that’s the cause.
5. Try ssllabs.com/ssltest — paste in the domain and it’ll diagnose the cert from outside your network. Authoritative.

How to diagnose TLS errors as an operator

1. Run SSL Labs on your domain. If you don’t get an “A” or “A+” rating, fix what it flags before doing anything else.
2. Check openssl s_client -connect yourhost:443 -servername yourhost to see exactly what cert chain the server is sending.
3. Check expiration dates with openssl x509 -in cert.pem -noout -dates.
4. Verify chain is complete with openssl verify -CAfile chain.pem cert.pem.
5. Set up monitoring. Cert-expiration alerts at 30/14/7/1 days. Dead-man monitoring on auto-renewal jobs (alert if cron didn’t run).
6. Test with multiple clients. Curl, wget, a real browser, a mobile browser. Different stacks reveal different problems.

How a website operator prevents TLS errors

In order of impact:

• Use Let’s Encrypt with certbot for free, auto-renewing certs. Works for almost every public site.
• Set up monitoring on cert expiration. Don’t trust auto-renewal alone — monitor the actual cert as served, not just whether the renewal job ran.
• Use a wildcard cert (*.example.com) for sites with many subdomains. One cert covers them all.
• Always include the full chain in your server config. Run SSL Labs to verify.
• Audit cipher suites and protocol versions at least annually. Disable anything weak; require TLS 1.2+ for compatibility, prefer TLS 1.3.
• Maintain HSTS but be cautious with HSTS preload — it’s effectively irreversible. Don’t preload until you’re 100% confident in your TLS pipeline.
• Plan for cert renewal during planned maintenance, not on Friday afternoons.

How TLS errors show up in our monitoring

When our HTTPS probe runs and hits a TLS error, the request fails before any HTTP status code is returned. We mark that check as down (since the user-visible result is the same as a 5xx error — the page won’t load) and the cause field captures the TLS failure type when available. From a user’s perspective, an expired certificate and an HTTP 503 look identical: “site doesn’t work”, which is what our methodology page calls out as a key reason for the dual-signal monitoring approach.

If you’re seeing a spike in user reports for a site that’s been green for months and the cert is approaching its expiration date, that’s almost always the cause — and the operator has probably been paged within minutes. Most TLS errors clear in under an hour.

Related concepts

• HTTP 502 Bad Gateway — TLS failures between gateway and backend show as 502s to users.
• HTTP 503 Service Unavailable — distinct from TLS errors, but both prevent successful page loads.
• DNS resolution — DNS and TLS issues frequently coincide during infrastructure changes.
• Time to first byte (TTFB) — TLS handshake time is part of TTFB; slow TLS makes pages feel slow.

For real-time visibility into sites currently failing TLS validation, see our live outages feed. Cert-expiration outages typically appear in our monthly outage reports as well — they’re some of the most preventable incidents we track.