How Chromium Validates Certificate Transparency Logs

This article provides an overview of how the Chromium web browser enforces Certificate Transparency (CT) to secure TLS connections. Before trusting a server's TLS certificate, Chromium verifies that the certificate has been publicly logged by checking for cryptographic proofs called Signed Certificate Timestamps (SCTs). By evaluating the SCT delivery mechanism, verifying the cryptographic signatures against known public logs, and ensuring compliance with specific log diversity and certificate lifetime policies, Chromium prevents the covert use of misissued or malicious certificates.

1. Acquiring Signed Certificate Timestamps (SCTs)

When a user navigates to an HTTPS website, Chromium does not query Certificate Transparency logs directly in real-time, as doing so would slow down the connection and compromise user privacy. Instead, it relies on Signed Certificate Timestamps (SCTs). An SCT is a cryptographic promise from a CT log that a certificate will be added to the log within a specific timeframe, known as the Maximum Merge Delay (typically 24 hours).

Chromium accepts SCTs delivered during the TLS handshake via three methods:

  • X.509v3 Certificate Extension: The Certificate Authority (CA) embeds the SCTs directly into the certificate before issuing it to the server. This is the most common method.
  • TLS Extension: The web server delivers the SCTs during the TLS handshake using the signed_certificate_timestamp extension.
  • OCSP Stapling: The web server includes the SCTs within a stapled Online Certificate Status Protocol (OCSP) response during the handshake.

2. Cryptographic Signature Verification

Once Chromium extracts the SCTs from the TLS handshake, it must verify their authenticity. Chromium maintains a built-in list of recognized CT logs, which is regularly updated via the browser's component updater. This list contains the public key, operator information, and current status of every recognized log.

For each SCT received, Chromium performs the following checks:

  • It identifies which CT log issued the SCT using the Log ID included in the timestamp.
  • It retrieves the corresponding public key for that log from its internal list.
  • It verifies the cryptographic signature of the SCT over the certificate data.
  • It checks that the timestamp inside the SCT is in the past, rejecting any SCT that claims to have been issued in the future.

If the signature is valid, Chromium knows for certain that the specific CT log reviewed the certificate and promised to publish it.

3. Evaluating CT Log Status

A valid cryptographic signature is not enough; the log itself must be in good standing. Chromium checks the operational status of the log that issued the SCT against its internal list:

  • Usable: The log is actively trusted and accepting new certificates.
  • ReadOnly: The log is still trusted, but it is no longer accepting new certificates.
  • Retired: The log was once trusted, and its past SCTs may still be valid under specific conditions, but it is no longer active.
  • Rejected: The log has failed to meet compliance standards, and its SCTs are completely untrusted.

To pass validation, the SCTs must come from logs that were marked as "Usable" at the time the SCT was issued. Furthermore, at least one of the provided SCTs must come from a log that is still in the "Usable" state at the exact moment Chromium is validating the TLS connection.

4. Enforcing the Chromium CT Policy

After verifying the individual SCTs and the status of their respective logs, Chromium evaluates the collection of valid SCTs against its Certificate Transparency Policy. This policy requires redundancy to ensure that a single compromised or failing CT log cannot undermine the entire security model.

Chromium enforces two main criteria:

Quantity Based on Certificate Lifetime

The number of required SCTs depends on how the SCTs were delivered and the validity period of the TLS certificate:

  • Delivered via TLS Extension or OCSP Stapling: At least 2 valid SCTs are required, regardless of the certificate's lifetime.
  • Embedded in the Certificate: If the certificate is valid for 180 days or less, at least 2 valid SCTs are required. If the certificate is valid for more than 180 days, at least 3 valid SCTs are required.

Log Operator Diversity

To prevent a single organization from controlling the validation process, Chromium enforces operator diversity. The required SCTs cannot all come from logs run by the same organization. A certificate must be accompanied by valid SCTs from at least two distinct CT log operators (for example, one SCT from a Google-operated log and one SCT from a Cloudflare-operated log).

5. The Final Trust Decision

If the presented SCTs are cryptographically valid, originate from active logs, and satisfy both the quantity and diversity policies, Chromium deems the certificate compliant with Certificate Transparency. Assuming standard X.509 path validation also succeeds, the TLS connection is established.

If the certificate fails to meet any of these CT requirements, Chromium immediately aborts the TLS handshake, blocks the user from accessing the website, and displays a full-page security warning with the error code NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.