SecurityEngineering/Certificate Transparency

Certificate Transparency (CT) is a system that works to ensure that TLS web server certificates are verifiably publicly disclosed before they can be used, which allows for certificate misissuance to be detected.

Certificate Transparency Support in Firefox

The security engineering team is actively working to implement Certificate Transparency in Firefox. As of version 133, it is enforced in Nightly by default, meaning that every TLS web server certificate must be accompanied by sufficient certificate transparency information for Nightly to connect without showing an error page.

Certificate transparency is controlled by the preference security.pki.certificate_transparency.mode. A value of 0 disables CT entirely. 1 enables CT, but does not enforce it, allowing Firefox to collect telemetry on the implementation and the ecosystem. Setting this preference to 2 causes Firefox to enforce CT for certificates issued by roots in Mozilla's Root CA Program.

Known CT Logs

The list of known CT logs is compiled into Firefox. This list is derived from Chromium's list and is automatically updated each week in prerelease versions of Firefox.

Each log in the source list is in one of a number of states. Firefox disregards logs that are Pending or Rejected. Firefox considers logs that are Qualified, Usable, or ReadOnly to be Admissible. Firefox makes notes of logs that are Retired, along with the retirement time.

This information has a 10 week expiration time. That is, if 10 weeks have passed since the information has been updated (typically by updating Firefox itself), the implementation will no longer enforce certificate transparency.

CT Policy

Certificate transparency information can be delivered either as signed certificate timestamps (SCTs) embedded in the certificate itself or as SCTs stapled alongside the certificate (via the TLS handshake or in an OCSP response). For a connection to succeed, sufficient certificate transparency information must be provided using either of these methods.

For embedded SCTs, "sufficient" means at least N SCTs from distinct logs that were Admissible or Retired at the time of verification, where N is 2 for certificates with a lifetime of 180 days or less, and 3 otherwise. At least 1 of those SCTs must be from a log that was Admissible at the time of verification. Among those SCTs, at least 2 must be from distinct log operators.

For SCTs delivered via the TLS handshake or an OCSP response, "sufficient" means at least 2 SCTs from distinct log operators that were Admissible at the time of verification.

CT Log Policy

TK