How does a browser actually verify a certificate was logged in Certificate Transparency?

How does a browser actually verify a certificate was logged in Certificate Transparency?

Certificate Transparency (CT, RFC 6962) requires publicly-trusted certificates to be recorded in append-only logs, so mis-issuance is detectable. But the browser does not query a log at handshake time — that would leak browsing history and add latency. Instead it checks for an SCT (Signed Certificate Timestamp): a log's signed promise to publish.

An SCT can reach the client through three delivery channels, and the distinction is operationally important:

— Embedded in the certificate itself, as an X.509 extension. The CA submits a pre-certificate to logs, collects SCTs, and bakes them in before final issuance. This is the dominant path and requires nothing of the server operator.

— Via a TLS extension (signed_certificate_timestamp) in the handshake. The server supplies SCTs dynamically.

— Via an OCSP stapled response carrying the SCTs.

Chrome's policy historically demanded SCTs from a quorum of logs operated by independent parties, defending against a single compromised log fabricating timestamps. The Maximum Merge Delay (MMD) — typically 24 hours — is the window in which a log commits to actually publishing a promised certificate; a log that breaks this promise is itself distrusted.

Evidence vs. speculation: CT detects mis-issuance after the fact; it does not prevent it. The DigiNotar-class threat is mitigated by monitors watching logs, not by the handshake.

Further reading: RFC 6962; RFC 9162 (CT v2).

Bottom line: Browsers trust a signed promise (the SCT), not a live log query; embedded SCTs make compliance invisible to most server operators.