SSL/TLS Errors Explained and How to Fix Them Fast

SSL/TLS errors are among the most user-visible failures a website can have - browsers show a full-page warning instead of your content. Unlike a slow page load, there's no partial success: the connection is refused. This guide breaks down the most common error codes, what actually causes them, and the exact commands to diagnose and fix each one quickly.

Why TLS Errors Are Different from Other Outages

A 500 error or slow response still lets users see something. A TLS handshake failure blocks the connection before any content is transferred. That makes fast diagnosis critical - every minute a bad certificate is live translates directly into lost traffic and eroded trust.

NET::ERR_CERT_COMMON_NAME_INVALID (Hostname Mismatch)

This error means the certificate's Subject Alternative Names (SANs) don't include the hostname the browser requested.

Diagnose it:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Common causes:

• The certificate was issued for www.example.com but the server also answers on the bare example.com.
• A wildcard cert for *.example.com doesn't cover the bare apex domain (wildcards don't include the root).
• A load balancer routes multiple hostnames to a backend serving only one certificate (missing SNI configuration).

Fix: reissue the certificate with all required hostnames in the SAN list, or configure SNI-based certificate selection at the load balancer/reverse proxy layer.

NET::ERR_CERT_DATE_INVALID (Expired or Not Yet Valid)

Straightforward date failure. Check both bounds:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

If notBefore is in the future, your server clock is likely wrong - check NTP sync (timedatectl on Linux). If notAfter has passed, the renewal automation failed. See our companion guide on SSL monitoring for automated expiry checks that catch this before users do.

NET::ERR_CERT_AUTHORITY_INVALID (Incomplete or Untrusted Chain)

This is the error caused by a missing intermediate certificate, an internally-issued cert without a trusted root, or a self-signed certificate presented in production by mistake.

Diagnose the full chain:

openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null | grep "subject="

You should see the leaf, one or more intermediates, ending just before a root CA. If only the leaf appears, your server config is missing the chain file. Fixes by server:

Expired Intermediate Certificates

Even if your leaf certificate is fine, an expired intermediate breaks the entire chain. This is subtle because it often works in browsers that cache trusted intermediates but fails for curl, mobile apps, and IoT clients that don't.

openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null \
  | awk '/BEGIN CERT/,/END CERT/{print}' > chain.pem
csplit -z chain.pem '/BEGIN CERT/' '{*}' -f cert-
for f in cert-*; do openssl x509 -in "$f" -noout -subject -enddate; done

This splits the chain into individual certs so you can check the expiry of each one independently, not just the leaf.

OCSP and Revocation Errors

OCSP (Online Certificate Status Protocol) lets clients check whether a certificate has been revoked. Failures here manifest as slow handshakes or, with OCSP stapling misconfigured, outright rejection under strict client policies.

Check OCSP stapling:

openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A5 "OCSP Response"

If you see "OCSP response: no response sent", stapling isn't configured. Enable it in nginx with:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/fullchain.pem;
resolver 8.8.8.8 valid=300s;

Without stapling, clients query the CA's OCSP responder directly, adding latency and creating a single point of failure if that responder is slow or unreachable.

Mixed Content Warnings

Not a handshake failure, but closely related: a page served over HTTPS that loads scripts, images, or iframes over plain HTTP triggers browser warnings and, for active content like scripts, outright blocking.

Find mixed content sources quickly:

curl -s https://example.com | grep -oE 'src="http://[^"]+"|href="http://[^"]+"'

Fix by updating hardcoded http:// references to https:// or protocol-relative // URLs, and set a Content-Security-Policy header with upgrade-insecure-requests as a safety net.

Fast Diagnosis Checklist

When a TLS error is reported, run through this in order:

• Confirm the error type exactly - hostname mismatch, expiry, or chain error are fixed differently
• Run openssl s_client -showcerts to see everything the server actually sends
• Check notBefore/notAfter for both leaf and intermediate certs
• Verify SANs include every hostname routed to that certificate
• Check OCSP stapling status if handshakes are slow rather than outright failing
• Scan for mixed content if the padlock shows a warning rather than a full block

Monitoring to Catch These Before Users Do

Manually running these commands after a report comes in means you're always reacting. Continuous uptime monitoring combined with dedicated certificate checks catches hostname mismatches, chain breaks, and expiry drift automatically, alerting your team before a customer opens a support ticket. ServerInspector runs these validations from multiple global locations so you see exactly what real users see.

FAQ

Why does a certificate work in Chrome but fail in curl or a mobile app?

Chrome and other major browsers cache and pre-load trusted intermediate certificates, effectively hiding an incomplete chain misconfiguration. curl and most non-browser clients only trust what the server explicitly sends, exposing the missing intermediate immediately.

Is a self-signed certificate ever acceptable in production?

Only for strictly internal services where every client explicitly trusts your private CA. Public-facing services need certificates from a publicly trusted CA, or every visitor will see a hard browser warning.

What's the fastest way to tell a hostname mismatch from an expired cert?

Both throw different Chrome error codes: NET::ERR_CERT_COMMON_NAME_INVALID for mismatch, NET::ERR_CERT_DATE_INVALID for expiry. Running openssl x509 -noout -dates -text shows both the validity window and the SAN list in one command.

Does OCSP stapling failure block the connection entirely?

Usually not by itself - most clients fall back to "soft-fail" and continue without confirming revocation status. But it adds latency and reduces security assurance, and some hardened client configurations do hard-fail.

Can mixed content break my SSL padlock even if the certificate itself is fine?

Yes. Browsers evaluate the full page's resource origins, not just the top-level certificate. An otherwise perfect certificate still shows a warning if the page loads any active content over plain HTTP.

Debugging Handshake Failures with Verbose Output

When an error doesn't map cleanly to a standard browser error code, get the raw handshake trace:

openssl s_client -connect example.com:443 -tls1_2 -msg 2>&1 | head -n 60

This prints every TLS record exchanged during the handshake. Look for an early Alert message - the alert description (e.g., handshake_failure, unrecognized_name, bad_certificate) usually pinpoints the exact stage where negotiation broke down, which is especially useful for diagnosing SNI misconfiguration or cipher suite mismatches that don't map to a friendly browser error string.