Common SSL certificate errors, explained
Every certificate warning a browser shows collapses into one of five underlying causes. Two are things Lapsewatch watches for automatically — expiry and renewal failure, and a certificate that doesn’t match the domain it’s served on. The other three are chain and trust problems that no expiry monitor, ours included, will see coming.
No signup. Real results in about four seconds.
The five errors, in plain language
Browsers word these differently — ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID, and so on — but every one of them reduces to one of these five.
Certificate expired
The valid-to date has passed. Browsers block by default, with no grace period — a certificate is either inside its validity window or it isn’t. This is the one every monitoring tool, ours included, is built to catch first.
Not valid for this domain
The certificate is real and unexpired, but its SAN list doesn’t include the domain being requested — often a default vhost, a misrouted load balancer, or a reload that never picked up a renewed certificate. The padlock was never the problem; the routing was.
Untrusted issuer
The certificate wasn’t signed by a certificate authority the browser’s trust store recognizes — commonly a self-signed certificate left over from testing, or an internal CA meant for a company network, not the public web.
Incomplete chain
The server sent the leaf certificate but not the intermediate certificate linking it to a trusted root. Some browsers fetch the missing link themselves and show nothing wrong; others don’t — which is why this error looks inconsistent across devices.
Mixed content
The page itself loaded fine over HTTPS, but it pulls in a script, image, or stylesheet over plain HTTP. Browsers flag this with a different icon than a certificate warning — it isn’t a certificate problem at all, just one visitors lump in with the rest.
Which of these Lapsewatch actually watches for
Two, directly: expiry and renewal failure — tracked by watching whether the renewal cycle is actually turning, not by counting down days — and, since September 2026, whether the certificate served on a domain actually covers that domain’s name. Both come from connecting to the live server on port 443, never from a file on disk or a registrar record.
The other three are trust and configuration problems, not expiry problems, and we say so rather than imply otherwise: the certificate check reads metadata off the live handshake — issuer, expiry, serial, SAN — deliberately without validating the trust chain. An admitted gap beats a confidently wrong “all clear.”
SSL errors, answered
Why does my certificate say it’s not valid for this domain if it hasn’t expired?
Almost always a routing problem, not a certificate problem: a default web server vhost, a load balancer sending traffic to the wrong backend, or a config reload that never happened after a renewal. The certificate itself can be perfectly valid — its SAN list just doesn’t list the domain a visitor actually requested.
Does an SSL warning mean the site has been hacked?
Almost never. The overwhelming majority of certificate warnings come from an expired certificate, a misconfigured vhost, or a missing intermediate certificate — all boring operational issues, not evidence of compromise. A warning means “this connection can’t be verified as trusted,” not “this site is malicious.”
Can Lapsewatch catch a broken certificate chain or a self-signed certificate?
No, and it’s worth being direct about that: the certificate check reads metadata from the live TLS handshake — expiry, issuer, serial number, SAN — without validating the trust chain. It’s built to answer “did this renew on time and does it cover this domain,” not “would every browser trust this chain.” A chain or trust problem needs a dedicated SSL scan, not an expiry monitor.
Stop finding out about certificate problems from a visitor’s browser
Five domains free, forever, no card.
Start free