Upcoming changes for 3p applications relying on Chrome's CT Log Lists for CT enforcement

[Joe DeBlasio]

Hi ct-policy@,

Applications that use Chrome's CT log lists to enforce CT within their application risk breakage when Google makes necessary changes to our log list. This breakage causes not just pain for impacted applications, but also risks the safety and stability of Chrome's CT enforcement. Relying on Chrome's log lists without explicit permission from Google is a violation of Google's Acceptable Use Policy for our lists.

Google is rolling out changes to the log lists served to these CT-enforcing clients that decouple the log list used for Chrome from the log list used by unauthorized clients. As a result of these changes, unauthorized clients relying on these log lists for enforcement will need to make changes in order to avoid breakage. These changes target only those requests coming from unauthorized CT-enforcing clients, and will not impact requests to the v3 log list from CT log monitors, certificate submitters, or other members of the CT ecosystem.

First off, effective now, no additional CT logs will be added to the log lists served to impacted CT-enforcing clients. Applications enforcing CT using Chrome's log list will need to ensure that their applications use SCTs from the logs on these lists. As logs naturally turn down, it will gradually become more difficult to acquire the necessary SCTs to satisfy these applications' policies.

To make it possible to avoid breakage even after all logs included in the lists have been turned down, we will be adding two additional log "mimics" to these lists in the Usable state in the coming weeks. The "mimics" are just key pairs, and we're publishing the private keys. This provides a mechanism to acquire a policy-satisfying set of SCTs without incurring the burden of maintaining additional logs. These SCTs can be provided to impacted applications via the TLS extension or embedded directly in the certificate. Our hope is that CAs will be able to provide services to facilitate embedding these SCTs, and encourage CAs able to assist to chime in on this thread for easy reference.

Starting in July, Google will also perform a series of changes to the log lists served to CT-enforcing clients designed to temporarily break enforcing applications as an early warning sign to impacted developers. During these temporary breakages, the log lists will be reduced to include only the log mimics, ensuring that applications that take action to avoid breakage ahead of time will not be impacted.

These changes are described in more detail on our policy website.

Thank you to the many community members who have reached out privately with suggestions on our next steps, with a special thank you to Rob Stradling of Sectigo for suggesting the introduction of the log mimics.

Questions are very much welcome,

Joe, on behalf of the Chrome CT Team.

[Rob Stradling]

Thanks Joe, and Chrome, for adopting the log "mimics" idea.

> Our hope is that CAs will be able to provide services to facilitate embedding these SCTs, and encourage CAs able to assist to chime in on this thread for easy reference.

Sectigo intends to provide services for optionally (at customer request) embedding "mimic" SCTs, in addition to the expected quorum of CT-compliant SCTs.

---

From: Joe DeBlasio <jdeb...@chromium.org>
Sent: 22 January 2026 16:50
To: Certificate Transparency Policy <ct-p...@chromium.org>
Subject: [ct-policy] Upcoming changes for 3p applications relying on Chrome's CT Log Lists for CT enforcement

 

Hi ct-policy@ , Applications that use Chrome's CT log lists to enforce CT within their application risk breakage when Google makes necessary changes to our log list. This breakage causes not just pain for impacted applications, but also risks

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd

--
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 ct-policy+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFZs0S6cpeZ%3DTtjyxKa%2B0xfnAt8z%3DZz0%3DVP2NN9-O_5d6D9cVw%40mail.gmail.com.

[Matthew McPherrin]

> To make it possible to avoid breakage even after all logs included in the lists have been turned down, we will be adding two additional log "mimics" to these lists in the Usable state in the coming weeks

I'm not 100% clear on this, but what you're saying is you're fingerprinting clients (eg, by User-agent) and will serve a different version of the log list to them, which will include the two mimic logs?

Would you be willing to include the mimic logs in all_log_list.json (perhaps as retired, like the existing placeholder logs) so that those of us parsing SCTs using that file can easily identify the mimic SCTs?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/SJ0PR17MB472600556B4D9C6E807C0A42AA97A%40SJ0PR17MB4726.namprd17.prod.outlook.com.

[Joe DeBlasio]

Thanks for the questions!

 

I'm not 100% clear on this, but what you're saying is you're fingerprinting clients (eg, by User-agent) and will serve a different version of the log list to them, which will include the two mimic logs?

Correct. The mimic logs will only be included in the "frozen" version of the log lists. The v3 frozen version will only be served to clients identified as using the list to enforce CT. As the v2 log list is deprecated, we will include the mimics on all requests to that list. 

 

Would you be willing to include the mimic logs in all_log_list.json (perhaps as retired, like the existing placeholder logs) so that those of us parsing SCTs using that file can easily identify the mimic SCTs?

Yes, we can do that, although we will include them without a specified Chrome state similar to how we include test logs.

Joe

[Seo Suchan]

I think we need 3 mimics, Because some of those external clients could implemented 'at least 3 logs froe usable/readonly/retired if its lifetime is longer than 180 days'  part of rule from Chrome CT rule. while it was meant to pass even if one of logs in SCT rejected, but in this case I don't think they can get a retired log in that list to still accepting new certs and give SCT.

2026년 1월 23일 금요일 AM 3시 50분 44초 UTC+9에 Joe DeBlasio님이 작성:

[Joe DeBlasio]

Hi Seo,

We will not be adding a third mimic. Clients that need to use this log list will need to use certificates with a lifetime less than 180 days. Please note that the CA/Browser Forum Baseline Requirements already mandate that publicly trusted certificates issued on or after March 15, 2026 have a maximum validity period of 200 days.

Best,

Joe

[Rob Stradling]

> Clients that need to use this log list will need to use certificates with a lifetime less than 180 days.

IINM, the CT policy for the legacy appmattus library requires only 2 SCTs if the certificate validity period is less than 15 months (which is approximately 456 days):

https://github.com/appmattus/certificatetransparency/blob/1.0.0/certificatetransparency/src/main/kotlin/com/appmattus/certificatetransparency/internal/verifier/DefaultPolicy.kt#L48

If that's correct, a <=398 day certificate (or <=200 days from March 15th) that embeds 3 "modern" SCTs plus 2 "mimic" SCTs should be compatible with both modern clients and with clients that use the legacy appmattus library.

Does anyone know of any other legacy CT clients/libraries/policies that the use of mimics needs to consider?

---

From: Joe DeBlasio <jdeb...@chromium.org>
Sent: 03 February 2026 01:34
To: Seo Suchan <tjt...@gmail.com>
Cc: Certificate Transparency Policy <ct-p...@chromium.org>; Rob Stradling <r...@sectigo.com>; Matthew McPherrin <ma...@letsencrypt.org>
Subject: Re: [ct-policy] Upcoming changes for 3p applications relying on Chrome's CT Log Lists for CT enforcement

 

Hi Seo, We will not be adding a third mimic. Clients that need to use this log list will need to use certificates with a lifetime less than 180 days. Please note that the CA/Browser Forum Baseline Requirements already mandate that publicly trusted

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd