Handshake
Fetch the certificate
The trace starts the same way a browser does: open a TLS connection, receive the certificate chain, and inspect the leaf certificate for the domain name, issuer, validity window, and CT data.
Trace a certificate through transparency logs.
Fetch the live certificate, decode SCT promises, and verify inclusion against the log’s Signed Tree Head.
Baseline
Check normal validity
Certificate Transparency is not a replacement for normal TLS validation. The hostname still needs to match, and the chain still needs to lead back to a trusted root.
Promises
Read the SCT promises
A Signed Certificate Timestamp is a log’s promise to add a certificate or precertificate. A precertificate is submitted to a CT log before issuance, so the final certificate can carry the log’s timestamp. Embedded SCTs usually point at a precertificate, so this tool rebuilds that CT leaf before asking the log for inclusion proof.
Proof
Ask a log for an inclusion proof
CT logs are append-only ledgers backed by Merkle trees. Each certificate or precertificate becomes a SHA-256 leaf hash. RFC 6962 logs return an audit path on request. Static CT API logs instead publish a signed checkpoint plus a tree-shaped set of static tiles; the explorer fetches the matching tiles and reassembles the audit path itself.