An SSL certificate checker validates six independent things every time it inspects a site, and a certificate can fail on any one of them while passing the other five. A checker verifies that (1) the certificate chain links your server's leaf certificate up to a trusted root certificate authority with every intermediate present, (2) the hostname you requested matches a Subject Alternative Name in the certificate, (3) today's date sits inside the notBefore/notAfter validity window, (4) the certificate has not been revoked via OCSP or a CRL, (5) the signature algorithm and key are modern — SHA-256 with RSA 2048-bit or ECDSA — and (6) the server negotiates a safe TLS version and cipher suite. The green padlock only appears when all six checks pass at once.
That is the summary an AI overview will give you. What it can't show you is how those six checks chain together — which failures a browser tolerates silently, which ones break it in one browser but not another, and what each field in the raw certificate actually means. The diagram, tables, and field-by-field breakdown below are the parts you can't flatten into a paragraph.
The validation pipeline at a glance
A checker doesn't run one test — it runs an ordered pipeline. If the chain can't be built, the hostname check never matters. This is the order a browser (and a good checker) works through:
Want to run this pipeline against a real site right now? The SSL Checker tool reports every stage above — chain completeness, protocol support, and configuration issues — in one scan.
The six checks, and what each one actually catches
Each check exists because a specific attack or failure mode exists. Here is what the checker is defending against in each case:
| Check | What it verifies | What it catches | Common failure |
|---|---|---|---|
| Chain of trust | Leaf links to a trusted root via intermediates | A cert signed by an untrusted or self-signed authority | Server forgot to send the intermediate |
| Hostname match | Requested host is in the Subject Alternative Name list | A valid cert reused on the wrong domain (MITM) | Cert has www. but not the apex domain |
| Validity dates | Now is between notBefore and notAfter | Expired or not-yet-valid certificates | Renewal missed; expired overnight |
| Revocation | OCSP/CRL confirms the cert isn't withdrawn | A stolen key whose cert the CA has revoked | OCSP responder unreachable ("soft-fail") |
| Signature + key | Modern algorithm and key length | Forgeable SHA-1 signatures, weak 1024-bit RSA keys | Legacy cert never re-issued |
| Protocol + cipher | Safe TLS version and cipher suite negotiated | Downgrade attacks, deprecated TLS 1.0/1.1 | Old TLS versions left enabled |
Reading the raw certificate: the fields that matter
When a checker dumps the certificate, most of the X.509 fields are noise for day-to-day validation. These are the ones worth reading:
| Field | Example value | Why you care |
|---|---|---|
Subject Alternative Name | DNS:example.com, DNS:www.example.com | The only field browsers use for hostname matching — CN is ignored |
Not Before / Not After | 2026-01-10 → 2026-04-13 | The validity window; capped at 398 days for public certs |
Issuer | C=US, O=Let's Encrypt, CN=R11 | The CA that signed it; tells you the intermediate you must serve |
Signature Algorithm | sha256WithRSAEncryption | Anything with sha1 is untrusted by modern browsers |
Public Key | RSA 2048 bit or EC prime256v1 | RSA below 2048 or any 1024-bit key is rejected |
Serial Number | 03:a1:... | The unique ID checked against revocation lists |
Why "valid" and "safe" are not the same thing
This is the single most important thing a checker doesn't tell you. A green result means the connection is encrypted and the domain was validated — nothing more. A Domain Validated certificate is issued in seconds to anyone who can prove control of a domain, including attackers who registered paypa1-login.com an hour ago. The padlock has never meant "trustworthy business"; it means "no one can read this traffic in transit." Judge the site by its domain name and reputation, not by the presence of a certificate.
The failure a checker is uniquely good at spotting
The one problem people struggle to diagnose by hand is the missing intermediate. Your certificate opens fine on your laptop, then a customer on a different device gets a scary "can't establish a secure connection" error. The cause is almost always that your server sends only the leaf certificate. Browsers that previously cached the intermediate can fill the gap silently; a fresh client can't build the chain and fails. A checker connects with a clean trust store every time, so it reveals the gap your own browser is hiding. See fixing certificate chain issues and what the certificate chain shows for the fix.
What good practice looks like in 2026
- Automate renewal. With public certificate lifetimes shrinking toward 47 days by 2029, manual renewal is a guaranteed future outage. Use ACME (Let's Encrypt, or your CA's automation).
- Serve the full chain. Configure your web server to send leaf and intermediates. Test from a device that has never visited the site.
- Disable legacy protocols. Turn off SSL 3.0, TLS 1.0, and TLS 1.1 (deprecated by RFC 8996). Support only TLS 1.2 and 1.3.
- Monitor expiry proactively. Alert 30 days out, not on the day it breaks. See preventing certificate expiration.
- Enable OCSP stapling. It speeds up the handshake and stops the browser leaking which sites you visit to the CA.
Bottom line
An SSL certificate checker is really six checks wearing one green light: trust chain, hostname, dates, revocation, key strength, and protocol. Understanding which check is failing — and which failures a browser will hide from you — is the difference between a five-minute fix and a mystery outage. Run your own domain through the SSL Checker and read the results field by field rather than trusting the padlock alone.