How to Read Your SSL Certificate Checker Results

Every padlock icon in a browser's address bar represents a real, verifiable handshake: the server proved it holds the private key matching a certificate that some trusted authority vouched for, and everything after that point is encrypted. When any part of that chain is wrong — expired, self-signed, missing a link, or just old and weak — browsers react in ways that range from a quiet downgrade to a full-page red warning that scares visitors away entirely.

Our SSL Certificate Checker opens a real TLS connection to whatever domain you enter and reports back exactly what a browser would see. This is a field-by-field walkthrough of that report.

Using the tool#

There's one input: type a domain (a bare hostname like example.com, or a full URL — we'll extract the hostname either way) and hit Check. We connect to that host on port 443 from our own servers, which is the one real limitation worth knowing: we can't check anything on your private network or behind a firewall, only what's actually reachable from the public internet — which, for a certificate a real visitor needs to trust, is exactly what matters.

The summary ring and verdict#

The circle at the top of your results is the fastest signal: it's summarizing whether the certificate is currently valid, trusted by a public certificate authority, and not about to expire. The verdict line underneath spells out why. If you see anything other than a clean "trusted" verdict, the detail fields below will tell you exactly which of the three went wrong.

Expiry: valid from / valid to#

Certificates are deliberately short-lived. A public CA-issued cert is typically valid for somewhere between 90 days (Let's Encrypt's default) and about a year — this is by design, not a limitation: a shorter lifetime shrinks the window a compromised or mis-issued certificate stays trusted, and the industry has been steadily pushing max lifetimes down for exactly that reason.

The important part is what happens the moment a certificate expires: there's no grace period and no gradual warning to visitors. One moment the site loads normally; the next, every browser hitting it shows a full-page interstitial warning, and most people will not click through. Unlike almost every other kind of outage, an expired certificate is entirely predictable — the expiry date has been sitting right there in the certificate since the day it was issued.

Issuer and trust#

The issuer field names the certificate authority (CA) that signed this certificate — Let's Encrypt, DigiCert, Google Trust Services, and so on. The trusted result is a separate, more important signal: it's whether that issuer is one every major browser and OS already ships a trust anchor for.

When trust fails, the checker reports why. The common causes:

• Self-signed — the certificate's issuer and subject are the same entity. It's cryptographically valid, but no browser trusts it out of the box because anyone can self-sign a certificate for any name.
• Unknown/private CA — signed by a real CA, just not one in the public trust store (common for internal/corporate certificates that were never meant to be public-facing).
• Expired or not yet valid — the dates don't currently cover "now."
• Hostname mismatch — the certificate is real and trusted, just not issued for the domain you actually checked (see Subject/SAN below).

Subject and Subject Alternative Names (SAN)#

The subject is the primary name the certificate identifies (its Common Name). Modern browsers actually validate against the SAN list, not the subject — SAN is where every hostname a certificate is actually valid for gets listed, which is how a single certificate covers multiple domains, or a wildcard like *.example.com covers every subdomain at once.

If you check www.example.com and its SAN list only contains example.com (no www. variant), that's a real mismatch — the certificate is valid, just not for the exact hostname a visitor is loading.

Protocol support#

This matrix shows which TLS versions the server will actually negotiate: TLS 1.0, 1.1, 1.2, and 1.3.

Version	Status today
TLS 1.0 / 1.1	Deprecated. Every major browser has removed support, and PCI-DSS (the payment card industry's own security standard) has required these be disabled since 2018. If your server still accepts them, it's extra attack surface with zero benefit — no real client is negotiating down to these on purpose.
TLS 1.2	Still the current baseline almost everywhere. Fully fine to support.
TLS 1.3	The modern standard: a faster handshake and it drops support for the weak cipher suites 1.2 still allows as options. If a server doesn't offer 1.3 at all, that's usually just an old TLS library that's overdue for an update.

The subtlety people miss: a server accepting an old protocol doesn't mean any of its real visitors are using it — modern browsers negotiate the best version available automatically. The risk is that leaving it enabled at all gives an attacker attempting a downgrade attack something to downgrade to. Disabling 1.0/1.1 server-side removes that option entirely, for free, with no impact on real traffic.

Certificate chain#

Browsers don't trust your certificate directly — they trust a small set of root certificates baked into the OS or browser, and your certificate needs an unbroken chain of signatures up to one of those roots. In between sits one or more intermediate certificates.

This produces one of the most common — and confusing — real-world certificate bugs: a server that only sends its leaf certificate, without the intermediate. Browsers often paper over this silently, because they cache intermediates they've seen before from other sites and can reconstruct the chain themselves. But a client that doesn't have that intermediate cached — curl, a mobile app's HTTP client, an older device — fails outright, with no visible warning to explain why. The symptom is exactly "it works when I check it in Chrome, but our integration partner says it's broken."

Key type, key size, and fingerprints#

The key type is either RSA or EC (elliptic curve). Both are secure at the sizes CAs issue today — RSA 2048-bit or EC P-256 and above are the current baseline; nothing smaller should be issued by any public CA in 2026. Bigger RSA keys (4096-bit) aren't meaningfully "more secure" in practice for a public web certificate and cost more CPU per handshake, so this isn't a field to chase upward.

The fingerprint fields (SHA-1 and SHA-256 hashes of the full certificate) are mostly useful for one thing: confirming that two systems — say, your CDN and your origin — are actually serving the exact same certificate, by comparing this one value instead of every other field by hand.

OCSP stapling#

This is a nice-to-have, not a critical flag. Normally, a browser checking whether a certificate has been revoked makes a separate request to the CA. OCSP stapling has the server proactively attach ("staple") a signed, time-stamped proof of non-revocation to the handshake itself, saving that extra round trip. If it's off, nothing is broken — it's a small performance optimization most server software doesn't enable by default.

Common problems, at a glance#

Symptom	Likely cause
trusted: false, no other flags	Self-signed certificate, or issuer isn't in the public trust store
expired: true	Renewal didn't happen — usually a manual process that got missed
SAN doesn't include the domain you checked	Wrong certificate is bound to this hostname, or it's serving the default/wrong virtual host
Chain is only 1 certificate long	Server isn't sending its intermediate certificate
TLS 1.0/1.1 marked "supported"	Server config hasn't disabled legacy protocol versions