How does the certificate transparency check in Chrome work?

Skip to first unread message

Jimmy wang

May 19, 2022, 2:58:22 AM5/19/22
to Certificate Transparency Policy
How does Chrome check if the certificate presented by the web server is present in the CT logs?
Does it actually make a request to CT logs to verify this (I doubt this as it will add latency to the TLS handshake proces)?
Where can I see the correct answer?

Mohammadamin Karbasforushan (Amin Karbas)

May 19, 2022, 3:40:35 AM5/19/22
to Jimmy wang, Certificate Transparency Policy
You are asking about SCT auditing. I’ll give a high level explanation of the whole process; but you can directly refer to the last paragraph.

High level
When a certificate is submitted to a log, the log returns an SCT: a Signed Certificate Timestamp. SCTs are cryptographic proofs of inclusion. The web server includes SCTs in its response to Chrome (or any other user agent) either via OCSP Stapling or by embedding the SCTs in the certificate as a TLS extension.
Chrome requires a TLS certificate to come with a certain number of SCTs, via either method.

A good starting point is (see the User Agents section).
For more details of CT, see RFC 6962 (
Also, as pointed in the first link, the Chrome policy is here: Specifically, see for Chrome’s CT policy.

Finally, the issue that you are talking about is called SCT auditing: Even though a log may issue an SCT for a certificate, it can maliciously(/etc.) not include that certificate. Therefore, user agents (e.g., Chrome) may have to do an extra check to make sure the logs are acting correctly. But, this may raise privacy issues. User agents (e.g., Chrome) may leak the full browsing history of a user when checking the SCTs that the user receives.
See and for Chrome’s current approach to this.
> --
> You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> To view this discussion on the web visit

Message has been deleted

Joe DeBlasio

Oct 24, 2023, 2:51:11 PM10/24/23
to David Laun, Certificate Transparency Policy, Mohammadamin Karbasforushan (Amin Karbas), Jimmy wang
Hi David,

That's correct -- no SCT auditing happens when users have opted out of Safe Browsing protections.

There are three possible states:
  • No Safe Browsing protections -> no SCT auditing
  • Default Safe Browsing protections -> SCT auditing logic selects a small proportion of TLS connections and performs a k-anonymous lookup on an SCT. If that privacy-preserving SCT lookup reveals that the SCT is not known to Google but should be, the client uploads the certificate, SCTs, and hostname to Google (but no other information).
  • Enhanced Safe Browsing protections -> SCT auditing logic selects a small proportion of TLS connections and uploads the certificate, SCTs, and hostname to Google (but no other information).
We currently have no plans to change from this structure, but even if we did, we would ensure that SCT auditing was disabled when Safe Browsing protections are disabled. We consider that a pretty clear signal that the device owner does not want to contact Google for security-related issues.

It's also important to note that SCT auditing is only enabled on certificates that chain to publicly-trusted roots. If a device has a custom root certificate installed, CT inclusion is not enforced, and thus SCT auditing is not enabled, for certificates using those custom roots. 

Joe, from Chrome's CT team

On Tue, Oct 24, 2023 at 11:18 AM David Laun <> wrote:

is there any possible update on SCT auditing? Has the behaviour changed? We rely on the statement that SCT audting ist not active for clients with Safe Browsing disabled. Is this still true?

Thank you

Reply all
Reply to author
0 new messages