Common SSL/TLS Errors and How to Fix Them

Most SSL/TLS errors come from one of four causes: the certificate expired, the name does not match the site, the issuing chain is broken, or the issuer is not trusted. Once you know which of those you are looking at, the fix is usually quick. This guide maps each common browser warning to its root cause and the concrete step that clears it. For the underlying concepts, see SSL/TLS certificates explained.

Every warning you see traces back to a rule in the certificate standard or the rules certificate authorities agree to follow. The structure of a certificate, including validity dates and the names it covers, is defined in the X.509 certificate profile, and what authorities are allowed to issue is governed by the CA/Browser Forum Baseline Requirements. Browsers enforce both. When something violates them, you get a blocked page. The full picture lives in SSL/TLS certificates explained.

Quick reference

Error	Cause	Fix
Certificate expired (NET::ERR_CERT_DATE_INVALID)	The current date is past the certificate's notAfter date	Renew and reinstall the certificate; automate renewal
Name mismatch (NET::ERR_CERT_COMMON_NAME_INVALID)	The visited hostname is not in the Subject Alternative Names	Reissue with the correct names, or redirect to the covered hostname
Untrusted issuer or self-signed (NET::ERR_CERT_AUTHORITY_INVALID)	The chain does not reach a trusted root	Use a publicly trusted CA, or install the root on managed devices
Incomplete chain	A required intermediate certificate is missing	Install the full chain (leaf plus intermediates) on the server
Revoked certificate (NET::ERR_CERT_REVOKED)	The CA marked the certificate invalid before expiry	Reissue a fresh certificate and remove the revoked one
Mixed content	An HTTPS page loads assets over HTTP	Serve every asset over HTTPS

Certificate expired

Certificates carry a hard end date. Once the clock passes the notAfter value, browsers stop trusting it, often the same morning a renewal was forgotten. The fix is to renew with your authority and install the new certificate, then reload the service that serves it. Because the Baseline Requirements keep shortening maximum lifetimes, manual renewal is a recurring trap; set up automated renewal (for example through ACME) so it never lapses. Worth checking before anything else: a server with the wrong system clock can make a valid certificate look expired.

Name mismatch

You will see NET::ERR_CERT_COMMON_NAME_INVALID when the certificate is otherwise fine but does not cover the exact hostname in the address bar. A common version: the certificate lists example.com but not www.example.com, or the other way around. Browsers match strictly against the Subject Alternative Names field, not the older common name. Two ways out. Reissue the certificate with every hostname it needs to serve, or redirect visitors to the name the certificate already covers. A wildcard certificate covers one label of subdomains, which often solves the www case in a single stroke.

Untrusted issuer or self-signed

NET::ERR_CERT_AUTHORITY_INVALID means the browser walked the chain and could not connect it to a root in its trust store. Self-signed certificates trigger this every time, since nothing vouches for them. Internal certificate authorities do too, unless their root has been distributed to the devices in question. For a public website, switch to a publicly trusted CA. For an internal tool, either install the internal root on the machines that need access or move to a public certificate.

Incomplete chain

This one is sneaky: the certificate is valid and from a trusted authority, yet some visitors still get an error while others do not. The cause is a missing intermediate. Servers must send the leaf certificate plus every intermediate up to (but not including) the root, so the browser can build a complete path. Some browsers cache intermediates from earlier visits and paper over the gap, which is why the failure looks intermittent. Install the full chain bundle on the server and the problem disappears for everyone. To confirm what the server actually sends, walk through how to check a website's SSL certificate, and for the trust logic itself, read SSL certificate chains explained.

Revoked certificate

Revocation is a CA declaring a certificate invalid before its natural expiry, usually after a key compromise or misissuance. When a browser learns of it, you get NET::ERR_CERT_REVOKED. You cannot un-revoke; the only path is a freshly issued certificate installed in place of the old one. If you requested the revocation yourself, make sure the replacement is already deployed before the old one is pulled.

Mixed content and protocol issues

A page served over HTTPS that pulls a script, image, or stylesheet over plain HTTP produces a mixed content warning, and browsers may block the insecure resource outright. Audit the page and rewrite every asset URL to HTTPS. Related failures show up when a server only offers outdated protocol versions a modern browser refuses to negotiate; the answer there is to enable current TLS versions and retire the old ones.

Not sure which error your domain is throwing, or whether the chain is complete? Run a free SSL check and get the expiry, names, chain, and issuer in one view.