What a TLS certificate actually does

When your browser connects to a site over https://, the server presents a digital certificate — a small file that says "I am example.com, signed by a trusted authority". The browser verifies the signature, checks the certificate hasn't expired, and confirms the domain on the certificate matches the one in the address bar. If any of that fails, you see the angry warning page.

How the grade is computed

We start from a valid, reachable HTTPS endpoint with a SAN that matches the queried hostname (anything less is an automatic F) and adjust from there. The strongest signal under our reach is the HSTS header: its presence, the max-age duration, and whether includeSubDomains and preload are set. Imminent expiry (under 30 days) takes points off; under 7 days takes more.

Grade	Criteria
A+	Valid cert, HSTS with max-age ≥ 1 year, includeSubDomains, preload directive.
A	Valid cert + HSTS present (typically with a year-plus max-age).
B	Valid cert; HSTS missing or weak.
C	Valid cert but expiring soon (≤ 30 days) and no HSTS, or other minor issues.
D	Cert exists in CT log but HTTPS doesn't respond, or expiring within 7 days.
F	Expired, revoked, hostname mismatch, or no valid cert at all.

What we can and can't check

We don't run a raw TLS handshake against the target — that requires a TCP socket, which Cloudflare Workers don't expose. So we cannot enumerate supported protocol versions, supported cipher suites, or the full intermediate-to-root chain. Tools like Qualys SSL Labs and OpenSSL's s_client are the right call for that. What we can do — and what most users actually want — is verify the certificate is valid and matches the hostname, hasn't been revoked, isn't expiring soon, and that the server is presenting HSTS correctly. The grade reflects those signals honestly.

How this tool works

Two parallel requests: a query against the public Certificate Transparency logs via SSLMate's certspotter API, and a HEAD request to https://{domain}/ to read the HSTS header and confirm the origin is actually serving HTTPS. The most recent unexpired CT entry for the domain is, in practice, the certificate currently deployed.

That gives us: subject CN, SANs, issuer, validity window, SHA-256 fingerprint, revocation status, HSTS configuration, and a computed grade. Want full handshake details (TLS version, ciphers)? Use the HTTP Headers tool or run openssl s_client -connect domain:443.

What the chain of trust means

A certificate isn't trusted directly. It's signed by an intermediate certificate, which is itself signed by a root certificate. Your browser ships with a small set of trusted root certificates baked in. Trust flows from the root down to the leaf: I trust DigiCert Root → DigiCert Root signed Intermediate → Intermediate signed example.com's cert → therefore I trust example.com's cert. If any link is missing or mis-signed, the chain breaks. We show the leaf cert and the immediate issuer as a synthesised intermediate. For full chain verification, use a live-handshake tool.

What to do if a certificate is expired or invalid

Expired: the site owner needs to renew. Modern certificates from Let's Encrypt last 90 days; the renewal process is usually automated, so an expiry suggests automation has broken.
Hostname mismatch: the certificate is valid but for a different domain. Common cause: someone visiting a site through a CDN's bare IP, or by IP address directly.
Self-signed or unknown CA: the certificate isn't signed by a publicly trusted authority — so it never gets logged to CT and won't appear here. If a domain returns "no certificates found", a self-signed or internal-CA cert is one possibility.
Revoked: the certificate has been pulled by its issuer before its expiry date, usually because the private key leaked. CT logs don't carry revocation status; for that you'd check OCSP or the issuer's CRL.

Inspect & grade the certificate.