Announcement: Chrome requiring Certificate Transparency in 2017

Skip to first unread message

Ryan Sleevi

Oct 24, 2016, 8:45:26 PM10/24/16
[Note: This is cross-posted. The best venue for follow-up questions is the public mailing list at or the post at ]
[Note: Posting wearing my Chrome hat. None of this reflects Mozilla policy, but is useful for the Mozilla community to be aware of]

This past week at the 39th meeting of the CA/Browser Forum, the Chrome team announced plans that publicly trusted website certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency policy in order to be trusted by Chrome.

The Chrome Team believes that the Certificate Transparency ecosystem has advanced sufficiently that October 2017 is an achievable and realistic goal for this requirement.

This is a significant step forward in the online trust ecosystem. The investments made by CAs adopting CT, and Chrome requiring it in some cases, have already paid tremendous dividends in providing a more secure and trustworthy Internet. The use of Certificate Transparency has profoundly altered how browsers, site owners, and relying parties are able to detect and respond to misissuance, and importantly, gives new tools to mitigate the damage caused when a CA no longer complies with community expectations and browser programs.

While the benefits of CT are clear, we recognize that some CAs, browsers, or site operators may have use cases they feel are not fully addressed by Certificate Transparency, and so may have concerns over the October 2017 date. We encourage anyone who feels this way to bring their concerns to the IETF’s Public Notary Transparency WG (TRANS) so that these use cases can be discussed and cataloged. The information for this WG, and the documents it works on, is available at

Although the date is a year away, we encourage any participants that wish to have their use cases addressed to bring them forward as soon as possible during the next three months. This will ensure that the IETF, the CA/Browser Forum, and the broader community at large have ample time to discuss the challenges that may be faced, and find appropriate solutions for them. Such solutions may be though technical changes via the IETF or via policy means such as through the CA/Browser Forum or individual browsers’ root program requirements.

We will continue outreach to CAs in trust stores used by Chrome to ensure that they are prepared and that there is minimal user disruption.

To further support these investments in Certificate Transparency, the Chrome team will be discussing a proposed new HTTP header at next month’s IETF meeting that would allow sites to opt-in to having CT requirements enforced in advance of this deadline.

Similarly, we welcome and encourage all CAs to voluntarily request that browsers enforce CT logging of their new certificates before this deadline. Doing so enhances CT's ability to protect users, detect misissuance, and in the unfortunate event that misissuance does occur, to confirm the scope of misissuance. This may allow browsers to take more targeted steps to remediate the problem than otherwise possible, thus minimizing any negative impact to their users.

Han Yuwei

Oct 25, 2016, 10:45:26 AM10/25/16
在 2016年10月25日星期二 UTC+8上午8:45:26,Ryan Sleevi写道:
Is there any timetable for enforcing CAs to support embedded CT or OCSP CT?

Nick Lamb

Oct 25, 2016, 11:39:31 AM10/25/16
On Tuesday, 25 October 2016 15:45:26 UTC+1, Han Yuwei wrote:
> Is there any timetable for enforcing CAs to support embedded CT or OCSP CT?

Well, the effect of Google's policy is that if you're a subscriber looking to obtain certificates a year from now you have three options

1. Don't care about Chrome (though of course this policy may spread to other browsers). That option might be attractive if your certificates are from the Web PKI but aren't usually examined by browsers. For example in a mail server, or in some financial applications. Otherwise it looks like a bad choice.

2. Arrange to implement the TLS SCT extension from your servers and obtain SCTs for yourself to pass on to browsers. This does not require any new effort from the CA. This would meet Chrome's requirement entirely and is very flexible, but can mean significant disruption or even the need for new software development. Most customers again will see this as an undesirable choice.

3. Choose a CA that can deliver SCTs with your certificates or maybe via OCSP and in the latter case ensure your server software is compatible with that.

I expect option (3) to be overwhelmingly popular, so that Google need do little or nothing in the way of "enforcing" this support. Indeed all the big public CAs either already have, or are known to be developing this capability.

Obviously Google needs to communicate this clearly to subscribers, and to a lesser extent to Chrome users. I think a simple announcement ought to be enough at this stage for CAs themselves, if you're operating a public CA in 2016 and don't know what Certificate Transparency is you're in the wrong business. But for the other two groups effective communication is important over the next 12-24 months. In the ideal world the CAs would take on some of the burden of informing their subscribers, but I think the SHA-1 experience shows that's not always a very reliable path.

Han Yuwei

Oct 25, 2016, 12:26:46 PM10/25/16
在 2016年10月25日星期二 UTC+8下午11:39:31,Nick Lamb写道:
First, I care about CT and I desperately want CT depolyment. I have tried to implement TLS SCT extension to my nginx but failed and I dont't why. Because I deployed OCSP stapling successfully so I want a embedded CT (best for everyone) or a OCSP response CT. So I am willing that CA could do more because they have much more resources than us.
Reply all
Reply to author
0 new messages