How Safari Verifies Certificate Transparency Logs

This article explains how the Safari web browser utilizes Certificate Transparency (CT) to validate newly issued TLS certificates before establishing a secure connection to a website. It covers the role and delivery methods of Signed Certificate Timestamps (SCTs), the cryptographic verification process against Apple's trusted log list, and the specific policy requirements a certificate must meet to be trusted by the browser.

The Role of Signed Certificate Timestamps (SCTs)

When you visit a secure website, Safari does not query massive public Certificate Transparency logs directly in real time, as doing so would slow down browsing and compromise user privacy. Instead, Safari relies on Signed Certificate Timestamps (SCTs).

An SCT is a cryptographic receipt issued by a CT log. It serves as a formal promise that a specific TLS certificate has been submitted to the log and will be publicly visible within a set timeframe, known as the Maximum Merge Delay (usually 24 hours). To trust a newly issued certificate, Safari requires proof of logging in the form of valid SCTs.

How Safari Receives SCTs

During the TLS handshake—the process where Safari and the web server establish a secure connection—the browser checks for SCTs accompanying the website's TLS certificate. Safari accepts SCTs delivered through any of the following three methods:

  1. X.509v3 Certificate Extension: The Certificate Authority (CA) submits a "pre-certificate" to the CT logs before issuing the final certificate. The logs return SCTs, which the CA embeds directly into the final TLS certificate.
  2. TLS Extension: The web server fetches SCTs from the CT logs and sends them directly to Safari using a specific TLS extension during the initial connection handshake.
  3. OCSP Stapling: The web server requests SCTs from the CA alongside the certificate's revocation status and "staples" this information to the TLS handshake.

Cryptographic Verification

Once Safari extracts the SCTs from the connection, it must verify their authenticity. Apple maintains a curated list of trusted, compliant CT logs. This list—which includes the public cryptographic keys for each log—is built into macOS and iOS and is updated automatically in the background by Apple.

Safari performs the following checks on each SCT:

  • Log Recognition: Safari checks the Log ID inside the SCT against Apple's built-in list of recognized CT logs.
  • Signature Validation: Using the corresponding CT log's public key, Safari verifies the digital signature on the SCT. This proves the SCT was genuinely issued by that specific log and has not been altered.
  • Certificate Matching: Safari ensures the cryptographic hash inside the SCT matches the exact TLS certificate presented by the website.
  • Timestamp Check: Safari verifies that the timestamp in the SCT is in the past, not the future.

Enforcing Apple's CT Policy

Cryptographic validity alone is not enough. Safari also enforces Apple’s specific Certificate Transparency policy to prevent any single compromised CT log or operator from undermining the system.

To pass Safari's verification, the presented SCTs must meet strict diversity and quantity rules:

  • Embedded SCTs: Because current Apple policy limits TLS certificate lifetimes to a maximum of 398 days, certificates with embedded SCTs must include at least two valid SCTs if the certificate is valid for 180 days or less, and three valid SCTs if it is valid for 181 to 398 days.
  • TLS or OCSP Delivered SCTs: If the SCTs are delivered via a TLS extension or OCSP stapling, Safari requires at least two valid SCTs, regardless of the certificate's validity period.
  • Operator Diversity: The required SCTs cannot all come from logs run by the same organization. A certificate must have SCTs from at least two different log operators (for example, one from a Google-operated log and one from a Cloudflare-operated log).
  • Log Status: The logs that issued the SCTs must be in a trusted state (categorized by Apple as "Usable," "Qualified," or "Read-only") at the time of the check.

The Final Trust Decision

Safari processes these CT checks in milliseconds alongside standard TLS validations, such as checking the certificate's expiration date and verifying the Certificate Authority chain.

If the SCTs are cryptographically valid and satisfy Apple's diversity policy, Safari trusts the certificate and loads the website. If the SCTs are missing, forged, or fail to meet the policy criteria, Safari immediately terminates the connection and displays a full-page warning alerting the user that the connection is not private.