Every browser SSL warning looks roughly the same at a glance — a red padlock and a vague “not private” message — but they map to a small, specific set of underlying causes, each with a different fix. An SSL Certificate Checker shows which one you're actually looking at directly, rather than guessing from the browser's generic wording.
Expired Certificate
The most common cause by far. Certificates are deliberately short-lived (public ones now cap at 398 days, many issued for 90) so a compromised certificate can't stay trusted indefinitely — the tradeoff is that renewal has to actually happen on schedule. An expired certificate almost always means an automated renewal job (Let's Encrypt's certbot, a hosting provider's auto-renewal, a CDN setting) silently failed rather than anyone forgetting manually. Fix: renew the certificate and confirm the automation that's supposed to handle this going forward is actually running.
Name Mismatch
The certificate is valid and trusted, but was issued for a different hostname than the one being requested — commonly www.example.com vs. example.com when only one was included, a subdomain missing from the certificate's SAN list, or a leftover certificate from a previous domain after a migration. Fix: reissue the certificate covering every hostname actually served, including both the bare domain and www if both are in use.
Self-Signed or Untrusted Issuer
The encryption itself is identical to any other certificate — the problem is trust, not security. Browsers only trust certificates issued by a recognized certificate authority; a self-signed one, or one from an issuer not in the browser's trust store, triggers a warning regardless of how correctly everything else is configured. Expected for internal tools and local development; a real problem on a public production site, where it should be replaced with a certificate from a trusted CA (Let's Encrypt is free and automatable).
Incomplete Certificate Chain
A certificate is trusted back to a root authority through one or more intermediate certificates. If a server serves only its own (“leaf”) certificate without the intermediates, most browsers fail validation even though the end certificate is perfectly valid on its own — some browsers cache intermediates from other sites and paper over the gap, which is exactly why this often “works for me” while failing for other visitors. Fix: serve the full chain (leaf plus intermediates) the certificate authority provides, not just the single certificate file.
Reading the Result
Run the SSL Certificate Checker against the domain to see the issuer, expiry date, and days remaining directly, rather than parsing the browser's own generic warning. Days remaining approaching zero explains an expiry-based error before it happens; an issuer that doesn't match what you expect, or a hostname mismatch flagged directly, points straight at which of the causes above you're dealing with.
Frequently Asked Questions
What does "your connection is not private" actually mean?
It's the browser's generic wrapper for any certificate problem — expired, wrong domain, untrusted issuer, or broken chain all show slight variations of this same warning. The specific error code underneath (visible if you click "Advanced" in most browsers, or shown directly by an SSL checker) is what actually tells you which of those it is.
Why does a certificate expire? Can't sites just renew forever?
Certificates are intentionally short-lived (most public ones now cap at 398 days, many far shorter) specifically so a compromised or outdated certificate can't stay valid indefinitely. Sites are expected to auto-renew before expiry; a certificate error from expiry almost always means an automated renewal job silently failed, not that expiry itself is unusual.
What causes a name mismatch error specifically?
The certificate is valid, but it was issued for a different hostname than the one being visited — commonly www vs. non-www, a subdomain not included in the certificate's SAN (Subject Alternative Name) list, or a certificate for an entirely different domain accidentally left in place after a migration.
Is a self-signed certificate always a problem?
Not inherently — it provides the same encryption as any other certificate. The issue is trust: browsers only trust certificates issued by a recognized certificate authority, so a self-signed one triggers a warning regardless of how correctly it's configured. Expected and fine for internal/development use; a red flag on a public production site.
What's an incomplete certificate chain?
A certificate is trusted through a chain back to a root authority, usually via one or more intermediate certificates. If a server serves only its own certificate without the intermediate(s), most browsers will still fail validation even though the end certificate itself is perfectly valid — this is a server misconfiguration, not a certificate problem, and it's one of the more common causes of "it works in my browser but not for visitors."
Run the SSL Certificate Checker against any domain to see its issuer, expiry, and validity directly.