Certificate, protocol, and history
A certificate check tells you about one specific certificate. A TLS scan tells you what protocol versions and ciphers the server will actually negotiate. A CT log search tells you every certificate that's ever existed for a domain, including ones you didn't issue. Together they cover most "is this site's encryption actually solid" questions.
📖 For a deeper walkthrough, see the guide: Your Certificate Renewed, So Why Is the Browser Still Angry?
SSL Certificate — issuer, expiry, and chain
SSL Certificate fetches and parses a server's certificate, showing the issuer (Certificate Authority), validity dates, Subject Alternative Names (SANs), and the certificate chain.
When to use it: checking when a certificate expires before it causes an outage, verifying a newly issued certificate covers every subdomain it should via its SAN list, or confirming the chain is complete — a missing intermediate certificate breaks validation for some clients even when browsers don't show an obvious error.
Reading results: a short validity period (90 days) is normal for Let's Encrypt and most modern CAs; it's a sign of automated renewal, not a red flag. What matters more is whether the chain is complete and whether the SAN list actually includes the hostname you're checking — a renewed certificate that's missing a subdomain will still trigger browser warnings even though it "renewed successfully."
TLS Scanner — what the server actually negotiates
TLS Scanner connects to a server and reports which TLS protocol versions (1.0 through 1.3) and cipher suites it supports.
When to use it: confirming old, insecure protocols (TLS 1.0/1.1) are actually disabled after a config change, compliance checks where a standard like PCI-DSS requires a minimum TLS version, or diagnosing why some older clients can't connect at all.
Reading results: TLS 1.2 and 1.3 should be the only versions a modern server offers — anything still supporting 1.0 or 1.1 is overdue for an upgrade. Within cipher suites, look for AES-GCM or ChaCha20; anything still offering RC4 or 3DES is a genuine weakness, not a minor style choice.
CT Log Search — the public record you can't opt out of
CT Log Search searches public Certificate Transparency logs — a record every publicly-trusted certificate is required to be published to — for every certificate ever issued for a domain, including subdomains you may have forgotten about.
When to use it: discovering subdomains you didn't know existed via certificates issued for them, detecting unauthorized or mis-issued certificates for your domain, or general security reconnaissance during an audit.
Reading results: a long list of expired certificates is completely normal — CT logs are permanent, and certificates renew every 90 days to a year, so history accumulates fast. What's actually worth investigating is a certificate from a CA you don't recognize, or one issued for a subdomain you don't control — either is a signal worth chasing down immediately.
How these fit together
Start with SSL Certificate for the specific domain you're worried about — it catches the most common issue (expiry, missing chain, wrong SANs). Run TLS Scanner separately when you need to verify protocol-level hardening, since a perfectly valid certificate can still sit on a server offering weak, outdated TLS versions underneath it. Reach for CT Log Search when the question is bigger than one certificate — auditing everything that's ever been issued for a domain, including things you didn't do yourself.