Security · updated 12 August 2026
SSL certificate errors explained (and how to fix each one)
NET::ERR_CERT_DATE_INVALID, name mismatch, incomplete chain, mixed content — what each browser warning actually means and the fix for it.
A certificate error is uniquely damaging because it does not degrade gracefully. There is no slow page or missing image: visitors get a full-screen red warning telling them your site may be dangerous, and most of them leave. The good news is that there are only about five distinct causes, and each has an unambiguous fix.
1. The certificate has expired
NET::ERR_CERT_DATE_INVALID. The most common outage of them all, and almost always caused by automated renewal failing quietly weeks earlier. Let's Encrypt certificates last 90 days and renew at 30 days remaining; if your SSL check shows fewer than 25 days left, renewal has already stopped working. Run the renewal manually, read the error, and fix the cause — usually a changed web root breaking the HTTP challenge, or a renewal hook that no longer reloads the web server.
Set a monitor as a backstop: a monitor fails when the certificate expires, so you find out from an email rather than from a customer.
2. The name does not match
NET::ERR_CERT_COMMON_NAME_INVALID. The certificate does not list the hostname the visitor typed. Remember that
example.com and www.example.com are different names and both must be listed, and that a wildcard
*.example.com covers exactly one level — it does not cover the bare domain, nor shop.eu.example.com.
Reissue with every name you serve on it.
3. The chain is incomplete
The classic bug that works on your laptop and fails on half of mobile devices and every API client. Your server must send
the intermediate certificates linking yours to a trusted root; browsers that have cached the intermediate from another site
paper over the problem, and everything else fails. If the chain section of a check shows only one certificate where it should
show two or three, install the full chain file your CA provided — fullchain.pem, not cert.pem.
4. Self-signed or untrusted issuer
The certificate was issued by something no browser trusts. Normal on an internal server, wrong on a public one. Note that if you use a proxy such as Cloudflare, an origin certificate issued by them is deliberately not publicly trusted — that is fine behind the proxy, and a full outage the moment the proxy is switched off.
5. Mixed content
The certificate is perfect but the page loads an image, stylesheet or script over plain HTTP. Browsers block the insecure
resource and drop the padlock. Fix the URLs at source — protocol-relative links and search-and-replace across the database
are the usual remedies — and add a Content-Security-Policy to catch regressions.
Rarer causes worth knowing
- The visitor's clock is wrong. A device set to next year sees every certificate as expired. If exactly one person has the problem, ask them the time.
- SNI not configured. Several sites on one IP, and the server hands out the wrong certificate. The check will show a name mismatch with a completely unrelated domain in it.
- Revoked certificate. Rare, but happens after a key compromise or a CA error. Reissue.
- Old TLS versions. A server offering only TLS 1.0 or 1.1 is refused outright by current browsers.
Preventing the next one
Automate renewal, then verify the automation works — the failure mode is silence. Check the expiry date monthly, or let something check it for you. Keep the whole certificate estate in one list; the certificate that expires is invariably the one on the subdomain nobody remembered was in production.