Please direct any questions about this Policy to the CT Policy forum: [email protected]
When a website’s TLS certificate is validated in modern versions of Chrome, it is evaluated for compliance against the Chrome CT Policy, except in rare circumstances where certain enterprise policies are set by an administrator. Certificates that are accompanied by SCTs that satisfy this Policy are said to be CT Compliant.
CT Compliance is achieved by a certificate and set of accompanying SCTs meeting a set of technical requirements enforced by the Chrome browser during certificate validation, which are defined in this Policy. The issuance of certificates that are not CT compliant is not considered mis-issuance or a violation of Chrome’s root program; such certificates will simply fail to validate in CT-enforcing versions of Chrome.
CT Compliance in Chrome is determined by evaluating SCTs from CT Logs and ensuring that these Logs are in the correct state(s) at time of check. The set of possible states a CT Log can be in is:
Pending,Qualified,Usable,ReadOnly,Retired, andRejected
In order to assist with understanding the requirements for CT compliance in Chrome, the definition of these states, the requirements of Logs in each state, as well as how these states impact Chrome behavior are described in detail in the CT Log Lifecycle Explainer.
A TLS certificate is CT Compliant if it is accompanied by a set of SCTs that satisfies at least one of the criteria defined below, depending on how the SCTs are delivered to Chrome. In CT-enforcing versions of Chrome, all publicly-trusted TLS certificates are required to be CT Compliant to successfully validate; however, certificates that are not logged to CT or have insufficient SCTs are not considered to be mis-issued or in violation of Chrome’s root program.
When evaluating a certificate for CT Compliance, Chrome considers several factors including how many SCTs are present, who operates the CT Log that issued the SCT, and what state the CT Log that issued the SCT was in, both at the time the certificate is being validated, and at the time the SCT was created by the CT Log.
Depending on how the SCTs are presented to Chrome, CT compliance can be achieved by meeting one of the following criteria:
Embedded SCTs:
- At least one Embedded SCT from a CT Log that was
Qualified,Usable,orReadOnlyat the time of check; and - There are Embedded SCTs from at least N distinct CT Logs that were
Qualified,Usable,ReadOnly, orRetiredat the time of check, where N is defined in the following table; and - Among the SCTs satisfying requirements 1 and 2, at least two SCTs must be issued from distinct CT Log Operators as recognized by Chrome.
| Certificate Lifetime | Number of SCTs from distinct CT Logs |
|---|---|
| <= 180 days | 2 |
| > 180 days | 3 |
SCTs delivered via OCSP or TLS:
- At least two SCTs from a CT Log that was
Qualified,Usable, orReadOnlyat the time of check; and - Among the SCTs satisfying requirement 1, at least two SCTs must be issued from distinct CT Log Operators as recognized by Chrome.
For both embedded SCTs and those delivered via OCSP or TLS, Log Operator uniqueness is defined as having separate entries within the operators section of log_list.json. In the rare situation that a CT Log changes operators during its lifetime, CT logs in the v3 log list schema optionally contain an list of previous_operators, accompanied by the final timestamp that this log was operated by the previous operator. To prevent log operator changes from breaking existing certificates, each SCT’s log operator is determined to be the operator at the time of SCT issuance, by comparing the SCT timestamp against the previous_operators timestamps, if present.
So long as one of the above CT Compliance criteria is met by some combination of SCTs presented in the handshake, additional SCTs, regardless of the status of the SCT, will not affect a certificate’s CT Compliance status positively or negatively.
In order to contribute to a certificate’s CT Compliance, an SCT must have been issued before the Log’s Retired timestamp, if one exists. Chrome uses the earliest SCT among all SCTs presented to evaluate CT compliance against CT Log Retired timestamps. This accounts for edge cases in which a CT Log becomes Retired during the process of submitting certificate logging requests.
"Embedded SCT" means an SCT delivered via the SignedCertificateTimestampList X.509v3 extension within the certificate itself. Many TLS servers do not support OCSP Stapling or the TLS extension, so CAs should be prepared to embed SCTs into issued certificates to ensure successful validation and/or EV treatment in Chrome.
The criteria for how CT Logs can become Qualified, as well as what circumstances can cause them to become Retired, can be found in the Chrome CT Log Policy.
Every day, Google publishes a new CT Log list that contains a fresh log_list_timestamp. These updated log lists are merged back to both Chromium top-of-tree as well as to Chrome release branches. When a new version of Chrome is released, it will enforce CT for 70 days (10 weeks) after its freshest log_list_timestamp.
Since Chrome 94, Chrome clients will also attempt to obtain updated CT Log lists from the Component Updater infrastructure several times per day. On a successful update of the CT Log list, Chrome will update the start of its 70 day CT enforcement window to the freshest log_list_timestamp.
If the installed version of Chrome has not applied security updates and has been unable to obtain an updated CT log list from the Component Updater for 70 days or more, then CT enforcement will be disabled. This timeout provides a critical assurance to the CT ecosystem that new CT Logs are able to safely transition to Usable within a fixed amount of time after becoming Qualified. All CT-enforcing user agents are strongly encouraged to implement a similar enforcement timeout to maximize compatibility with the existing ecosystem.