What your SSL check result actually means — every state explained

A domain check gives you a verdict — Healthy, Action needed, or Broken — and a single word for the certificate: Valid, Expired, Self-signed, Untrusted chain, Wrong host, or Status unavailable. Each of those words has a precise meaning, a specific cause, and a specific fix. This page is the map: find the result you got, understand exactly why it happened, and know what to do about it.

None of these states is mysterious once you know what the check is testing. Every certificate result here comes from one thing — a real TLS handshake to your domain, the same kind a browser makes, with full verification switched on. That single test answers three questions at once: is the certificate signed by an authority the browser trusts, is it issued for this exact hostname, and is it inside its validity dates? A Valid result means all three passed. Every other state is one of the three failing, and the state name tells you which one. So the glossary below is really just those three questions, answered in plain language.

"Valid" — but the browser still says "not secure"

The most confusing result isn't a failure: it's a certificate that checks out as valid while the browser's address bar still reads Not secure. This happens because a certificate secures one thing — the connection — and the browser's padlock judges the whole page. A perfect certificate can sit behind a page the browser still distrusts, for two common reasons.

You're seeing the plain-HTTP version. A certificate only protects https://. If your site doesn't redirect http:// requests to the secure address, visitors (and link previews, and old bookmarks) can still load the unencrypted page, which every modern browser marks "Not secure" no matter how good the certificate is. The fix is a permanent (301) redirect to HTTPS, ideally backed by HSTS — a response header that tells the browser to use HTTPS for your domain on every future visit and to stop offering an insecure fallback at all.

Mixed content. The page itself loads over HTTPS but pulls in a resource — an image, a script, a font, a stylesheet — over plain HTTP. Browsers treat that as a hole in the encryption: they block insecure active content like scripts and frames outright, try to silently upgrade insecure images and media to HTTPS, and downgrade the address bar to "Not secure" when they can't. The certificate is fine; the page is mixing secure and insecure loads. The fix is to serve every resource on the page over HTTPS.

One thing this is not: a certificate issued for the wrong hostname. That is a real verification failure, and the check reports it as Wrong host rather than Valid — covered below.

The broken states, one at a time

When verification fails, it fails for a reason, and the reasons are not interchangeable. Underneath, the prober reads the exact verification error — the same numbered codes the OpenSSL library uses — and sorts it into one of four buckets. Knowing which bucket you're in tells you what to fix.

Expired

The certificate's validity window has passed — or, less often, hasn't started yet. These are OpenSSL's "certificate has expired" and "certificate is not yet valid" results. An expired certificate almost always means a renewal that didn't run, or one that ran but produced a new certificate the web server was never told to load — so it keeps serving the old, now-dead one. "Not yet valid" is usually a clock problem: the server's date is wrong, or the certificate was installed before its start time. The fix is to renew and, crucially, reload the service so it picks up the new file; for "not yet valid", check the server clock.

Self-signed

The certificate was signed by itself — or by a private authority your browser has never heard of — instead of a public certificate authority in the browser's trust store. Self-signed certificates are not "weak": the encryption is identical to any other. What they lack is a trusted third party vouching that the certificate genuinely belongs to this domain, and that vouching is the entire point of public certificates. On a public site this usually means a development or internal certificate has been left facing the open web — or that something is intercepting the connection and presenting its own certificate, such as a corporate proxy, security software, or, in the worst case, an attacker. The fix for anything public-facing is to replace it with a certificate from a public authority (Let's Encrypt issues them free).

Untrusted chain

The certificate looks like it came from a real authority, but the browser can't build the path from it back to a root it trusts. The single most common cause is a missing intermediate certificate: the server sent its own certificate but not the intermediate that links it to the root. OpenSSL surfaces this as "unable to verify the leaf signature" (only one certificate was sent) or "unable to get local issuer certificate". This one is sneaky because it often works in one browser and fails in another — some clients have cached the intermediate from a previous site and quietly fill the gap, others haven't — so it looks intermittent and is easy to dismiss. The fix is to install the full chain (your certificate plus its intermediate). Renewal tools produce a "fullchain" file for precisely this reason; point your server at that, not the bare certificate.

Wrong host

The certificate is valid and trusted — but it was issued for a different name than the one you checked. The name you connected to simply isn't listed in the certificate's Subject Alternative Names, which is the field browsers check. Typical causes: a certificate for example.com being served on www.example.com or the reverse, a default placeholder certificate left in place by a host, or one server answering for a domain it was never configured for. The fix is to issue a certificate that lists every hostname you actually serve — commonly both the bare domain and its www form — and serve it on the right host.

"Days remaining" — when to act, when to ignore

A valid certificate also shows how long it has left. The raw number matters less than the buffer behind it. Certificates are meant to be replaced well before they expire, not at the last second. The widely used default — the one Let's Encrypt recommends and Certbot ships with — is to renew when about a third of the lifetime remains: 30 days out on a 90-day certificate. That buffer isn't superstition. If the first automated renewal fails, you want days of runway for it to retry before anything actually breaks.

That's why this check flags a certificate with seven days or fewer remaining as Action needed, even though it is still technically valid. Seven days is the point where, if automated renewal were going to work, it should already have — so a certificate still sitting that close to its expiry is a signal the automation may be stuck. Above that line, a slowly shrinking number on a domain that renews itself is completely normal, and you can ignore it. The trend only makes this more relevant: certificate lifetimes are themselves being cut, heading toward 47 days by 2029, which compresses every one of these windows. The shorter certificates get, the more "check occasionally that renewal is really happening" earns its keep — we cover that change in why SSL certificates are getting shorter.

Does the issuer matter? Free versus paid

A valid result also names who issued the certificate, which raises a question worth answering plainly: is a free certificate from Let's Encrypt somehow weaker than a paid one from a commercial authority? For the encryption itself, no — there is no difference. Both use the same cipher strengths and are trusted by the same browsers, provided the issuer sits in the browser root programs, which Let's Encrypt does. A visitor sees the identical padlock either way.

What you can pay more for is three things, none of which is encryption:

For an ordinary website, a free DV certificate that renews automatically is not a compromise. What actually determines whether your visitors are protected is whether the certificate is valid, trusted, issued for the right host, and current — exactly the four things this check looks at — not its price or brand.

Why the same domain can check differently from different places

Now and then a domain looks healthy in one tool and broken in another, or fine on your phone but not your laptop. There are a few honest reasons, none of which means a checker is lying:

These are the moving parts of two distributed systems — TLS and DNS — not a flaw in any one tool. When this check can't get a clean answer at all, because the prober couldn't reach the host or none is configured, it says Status unavailable rather than guessing. That is deliberately not the same as Broken: unknown means unknown, and the check will never report a healthy site as broken just because it couldn't look. The DNS side of that — why a record looks live in one place and stale in another — gets its own walkthrough in why your DNS change hasn't taken effect yet.

Check your own certificate

Run your domain below and match the certificate state against the sections above. You'll get the live issuer, validity, and days remaining alongside DNS and registration, rolled into one plain verdict — no signup.

The point of a result like this isn't the label — it's knowing what to do with it. Valid with a long runway: nothing to do. Action needed: confirm renewal is actually running. Expired, untrusted, self-signed, or wrong host: you now know which of the three underlying checks failed, and the fix follows directly from that. The check tells you the state; this page tells you why, and the why is what turns a red word into a five-minute fix.

Sources