Certificate Transparency Enforcement in Google Chrome

6001 views
Skip to first unread message

Devon O'Brien

unread,
Feb 6, 2018, 8:11:34 PM2/6/18
to Certificate Transparency Policy

In preparation for the upcoming CT enforcement in Chrome, we recently reached out to all CAs currently registered in CCADB with an update on timelines and implementation details pertaining to this change. I've included the content of this message below to share the information with the rest of the CT community.


The link to the CA survey was removed to prevent spurious responses, but if you are a CA reading this who did not receive this communiqué, please contact chrome-root-au...@google.com and we will provide you a survey link.


-----------------------------------------------------------------------------------------


Greetings CA Operators,


This notice is being sent to all CA Operators known to the Common CA Database [1] and applies to CAs that are currently, or may in the future be, trusted on platforms on which Chrome operates (Mozilla NSS, Microsoft Windows, Apple iOS/macOS, Google ChromeOS, and Android).


We’re writing to reiterate the upcoming April 2018 Certificate Transparency (CT) enforcement in Chrome. As was first announced [2] at the CA/B Forum, followed by announcements [3] on the mozilla.dev.security.policy forum, and later updated [4] in the referenced ct-policy forum, Chrome will start enforcing that all TLS certificates issued after April 2018 comply with the Chromium CT Policy [5] in order to be trusted.


Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted or enterprise CAs that are added by users or administrators are not subject to this requirement.


What is happening and when?


Chrome will require that all TLS server certificates issued after 30 April, 2018 be compliant with the Chromium CT Policy. After this date, when Chrome connects to a site serving a publicly-trusted certificate that is not compliant with the Chromium CT Policy, users will begin seeing a full page interstitial indicating their connection is not CT-compliant. Sub-resources served over https connections that are not CT-compliant will fail to load and will show an error in Chrome DevTools. CAs are strongly encouraged to work with their customers to ensure their TLS certificates are ready to comply with the Chromium CT Policy via any of the three means specified in RFC 6962 Section 3.3 [6] before the end of March to ensure that any issues with deploying CT support are resolved in advance of the enforcement deadline. These changes will be rolled out to Desktop platforms first, which include macOS, Windows, Linux, and ChromeOS.


In order to accommodate the unique needs of certain enterprises, there will be Chrome policies to disable CT enforcement on managed devices and for managed users that have signed-in to Chrome on their personal devices. In addition to the existing ability to disable CT enforcement by URL [7], Chrome will add a policy that allows organizations to disable CT enforcement for CAs that only issue certificates to that organization.


What do CAs need to do?


CAs issuing TLS certificates with embedded SCTs should ensure they are compliant with the requirements of Qualifying Certificates in the Chromium CT Policy in order to maintain functionality in Chrome. Enforcement of CT compliance will only apply to certificates issued after April 2018; certificates issued before this date are unaffected.


CAs may opt to include SCTs within the OCSP CT extension in their OCSP responses. However, please note that this will only allow compliance with RFC 6962 and the Chromium CT Policy if the site operator always staples these OCSP responses. Additionally, there is a different set of requirements for the SCTs included within a stapled OCSP response than for those embedded in certificates, which may require CAs to make rapid changes to their systems. If a CA is unable to make these changes, or if the site operator is unable to staple fresh OCSP responses, their certificate will become non-functioning. For this reason, CAs are encouraged to embed SCTs within TLS certificates they issue.


As a part of rolling out this change to certificate evaluation in Chrome, we’d like to hear from you and your progress towards CT compliance. Please fill out the following survey to answer questions and provide feedback about this upcoming requirement:


<Survey Link Removed>


In addition to completing the above survey, we encourage CAs to read through past discussions on Certificate Transparency in the ct-policy forum [8] and participate in discussions there going forward. If you have any further questions regarding the upcoming CT enforcement, we can be reached at Chrome’s new address for its Root Authority Program: chrome-root-au...@google.com.


Finally, we’d like to thank you for your efforts in helping us make the internet a more secure and accountable environment for its users.


[1] http://ccadb.org

[2] https://cabforum.org/pipermail/public/2016-October/008638.html

[3] https://groups.google.com/d/msg/mozilla.dev.security.policy/LtwXaA1VjfY/srNHJfCSAgAJ

[4] https://groups.google.com/a/chromium.org/d/msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ

[5] https://goo.gl/chrome/ct-policy

[6] https://tools.ietf.org/html/rfc6962#section-3.3

[7] https://www.chromium.org/administrators/policy-list-3#CertificateTransparencyEnforcementDisabledForUrls

[8] https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy

Weitsong Lin

unread,
Feb 8, 2018, 4:19:35 AM2/8/18
to Certificate Transparency Policy
Hello,

I would like know which version of Chrome will enable the CT enforcement policy?

Thanks,
Robin Lin

Devon O'Brien於 2018年2月7日星期三 UTC+8上午9時11分34秒寫道:

In preparation for the upcoming CT enforcement in Chrome, we recently reached out to all CAs currently registered in CCADB with an update on timelines and implementation details pertaining to this change. I've included the content of this message below to share the information with the rest of the CT community.


The link to the CA survey was removed to prevent spurious responses, but if you are a CA reading this who did not receive this communiqué, please contact chrome-root-authority-program@google.com and we will provide you a survey link.


-----------------------------------------------------------------------------------------


Greetings CA Operators,


This notice is being sent to all CA Operators known to the Common CA Database [1] and applies to CAs that are currently, or may in the future be, trusted on platforms on which Chrome operates (Mozilla NSS, Microsoft Windows, Apple iOS/macOS, Google ChromeOS, and Android).


We’re writing to reiterate the upcoming April 2018 Certificate Transparency (CT) enforcement in Chrome. As was first announced [2] at the CA/B Forum, followed by announcements [3] on the mozilla.dev.security.policy forum, and later updated [4] in the referenced ct-policy forum, Chrome will start enforcing that all TLS certificates issued after April 2018 comply with the Chromium CT Policy [5] in order to be trusted.


Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted or enterprise CAs that are added by users or administrators are not subject to this requirement.


What is happening and when?


Chrome will require that all TLS server certificates issued after 30 April, 2018 be compliant with the Chromium CT Policy. After this date, when Chrome connects to a site serving a publicly-trusted certificate that is not compliant with the Chromium CT Policy, users will begin seeing a full page interstitial indicating their connection is not CT-compliant. Sub-resources served over https connections that are not CT-compliant will fail to load and will show an error in Chrome DevTools. CAs are strongly encouraged to work with their customers to ensure their TLS certificates are ready to comply with the Chromium CT Policy via any of the three means specified in RFC 6962 Section 3.3 [6] before the end of March to ensure that any issues with deploying CT support are resolved in advance of the enforcement deadline. These changes will be rolled out to Desktop platforms first, which include macOS, Windows, Linux, and ChromeOS.


In order to accommodate the unique needs of certain enterprises, there will be Chrome policies to disable CT enforcement on managed devices and for managed users that have signed-in to Chrome on their personal devices. In addition to the existing ability to disable CT enforcement by URL [7], Chrome will add a policy that allows organizations to disable CT enforcement for CAs that only issue certificates to that organization.


What do CAs need to do?


CAs issuing TLS certificates with embedded SCTs should ensure they are compliant with the requirements of Qualifying Certificates in the Chromium CT Policy in order to maintain functionality in Chrome. Enforcement of CT compliance will only apply to certificates issued after April 2018; certificates issued before this date are unaffected.


CAs may opt to include SCTs within the OCSP CT extension in their OCSP responses. However, please note that this will only allow compliance with RFC 6962 and the Chromium CT Policy if the site operator always staples these OCSP responses. Additionally, there is a different set of requirements for the SCTs included within a stapled OCSP response than for those embedded in certificates, which may require CAs to make rapid changes to their systems. If a CA is unable to make these changes, or if the site operator is unable to staple fresh OCSP responses, their certificate will become non-functioning. For this reason, CAs are encouraged to embed SCTs within TLS certificates they issue.


As a part of rolling out this change to certificate evaluation in Chrome, we’d like to hear from you and your progress towards CT compliance. Please fill out the following survey to answer questions and provide feedback about this upcoming requirement:


<Survey Link Removed>


In addition to completing the above survey, we encourage CAs to read through past discussions on Certificate Transparency in the ct-policy forum [8] and participate in discussions there going forward. If you have any further questions regarding the upcoming CT enforcement, we can be reached at Chrome’s new address for its Root Authority Program: chrome-root-authority-program@google.com.

Doug Beattie (Globalsign)

unread,
Mar 2, 2018, 8:17:19 AM3/2/18
to Certificate Transparency Policy
Hi Devon,

I'm sure this survey will help you understand the readiness of the CAs and the features they are providing to their customers.

As a side note, we recently received a report that some of our SCTs were invalid, and after further research we discovered that the order of SANs and/or Extensions in the issued certificate were not always the same as those in the Precertificate.  We'll be able to resolve this before the April date, but I wonder who else might have some issues with their SCTs and not know it.

Do you think Google could run a report that lists recently issued certificates with invalid embedded SCTs for public disclosure?  I think this would help reduce the risk of widespread (hopefully not) issues starting in May.

Doug


On Tuesday, February 6, 2018 at 8:11:34 PM UTC-5, Devon O'Brien wrote:

In preparation for the upcoming CT enforcement in Chrome, we recently reached out to all CAs currently registered in CCADB with an update on timelines and implementation details pertaining to this change. I've included the content of this message below to share the information with the rest of the CT community.


The link to the CA survey was removed to prevent spurious responses, but if you are a CA reading this who did not receive this communiqué, please contact chrome-root-authority-program@google.com and we will provide you a survey link.


-----------------------------------------------------------------------------------------


Greetings CA Operators,


This notice is being sent to all CA Operators known to the Common CA Database [1] and applies to CAs that are currently, or may in the future be, trusted on platforms on which Chrome operates (Mozilla NSS, Microsoft Windows, Apple iOS/macOS, Google ChromeOS, and Android).


We’re writing to reiterate the upcoming April 2018 Certificate Transparency (CT) enforcement in Chrome. As was first announced [2] at the CA/B Forum, followed by announcements [3] on the mozilla.dev.security.policy forum, and later updated [4] in the referenced ct-policy forum, Chrome will start enforcing that all TLS certificates issued after April 2018 comply with the Chromium CT Policy [5] in order to be trusted.


Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted or enterprise CAs that are added by users or administrators are not subject to this requirement.


What is happening and when?


Chrome will require that all TLS server certificates issued after 30 April, 2018 be compliant with the Chromium CT Policy. After this date, when Chrome connects to a site serving a publicly-trusted certificate that is not compliant with the Chromium CT Policy, users will begin seeing a full page interstitial indicating their connection is not CT-compliant. Sub-resources served over https connections that are not CT-compliant will fail to load and will show an error in Chrome DevTools. CAs are strongly encouraged to work with their customers to ensure their TLS certificates are ready to comply with the Chromium CT Policy via any of the three means specified in RFC 6962 Section 3.3 [6] before the end of March to ensure that any issues with deploying CT support are resolved in advance of the enforcement deadline. These changes will be rolled out to Desktop platforms first, which include macOS, Windows, Linux, and ChromeOS.


In order to accommodate the unique needs of certain enterprises, there will be Chrome policies to disable CT enforcement on managed devices and for managed users that have signed-in to Chrome on their personal devices. In addition to the existing ability to disable CT enforcement by URL [7], Chrome will add a policy that allows organizations to disable CT enforcement for CAs that only issue certificates to that organization.


What do CAs need to do?


CAs issuing TLS certificates with embedded SCTs should ensure they are compliant with the requirements of Qualifying Certificates in the Chromium CT Policy in order to maintain functionality in Chrome. Enforcement of CT compliance will only apply to certificates issued after April 2018; certificates issued before this date are unaffected.


CAs may opt to include SCTs within the OCSP CT extension in their OCSP responses. However, please note that this will only allow compliance with RFC 6962 and the Chromium CT Policy if the site operator always staples these OCSP responses. Additionally, there is a different set of requirements for the SCTs included within a stapled OCSP response than for those embedded in certificates, which may require CAs to make rapid changes to their systems. If a CA is unable to make these changes, or if the site operator is unable to staple fresh OCSP responses, their certificate will become non-functioning. For this reason, CAs are encouraged to embed SCTs within TLS certificates they issue.


As a part of rolling out this change to certificate evaluation in Chrome, we’d like to hear from you and your progress towards CT compliance. Please fill out the following survey to answer questions and provide feedback about this upcoming requirement:


<Survey Link Removed>


In addition to completing the above survey, we encourage CAs to read through past discussions on Certificate Transparency in the ct-policy forum [8] and participate in discussions there going forward. If you have any further questions regarding the upcoming CT enforcement, we can be reached at Chrome’s new address for its Root Authority Program: chrome-root-authority-program@google.com.

Ryan Sleevi

unread,
Mar 2, 2018, 11:02:25 AM3/2/18
to Doug Beattie (Globalsign), Certificate Transparency Policy
On Fri, Mar 2, 2018 at 8:17 AM, Doug Beattie (Globalsign) <douglas...@gmail.com> wrote:
Hi Devon,

I'm sure this survey will help you understand the readiness of the CAs and the features they are providing to their customers.

As a side note, we recently received a report that some of our SCTs were invalid, and after further research we discovered that the order of SANs and/or Extensions in the issued certificate were not always the same as those in the Precertificate.  We'll be able to resolve this before the April date, but I wonder who else might have some issues with their SCTs and not know it.

That's interesting, we received a question from a CA software vendor regarding that. It would be interesting to know what vendor you use, to know if it is the same.

That's a very interesting problem to have manifest, since the ordering of a SEQUENCE is semantically relevant in ASN.1 (that is, SEQUENCE { A, B } is not the same meaning as SEQUENCE { B, A }, even in the case of a SEQUENCE OF). Understanding how this problem manifest would also be useful.

This does highlight the need for greater interoperability testing, although the number of open-source SCT verifiers suggest that there's already ample tooling around this.
 
Do you think Google could run a report that lists recently issued certificates with invalid embedded SCTs for public disclosure?  I think this would help reduce the risk of widespread (hopefully not) issues starting in May.

Do you log your certificates post-issuance?

Logging your precertificates, and then logging the full certificate (that is, with the SignedCertificateTimestampList), can greatly improve the visibility and diagnostics of the ecosystem. Logging the full certificates post-issuance is something that most CAs should be able to do today, as it does not require integration pre-issuance, and does not require a quorum of logs. While this is not sufficient to meet the CT Qualified definition in and of itself, it can provide valuable information about how the CA is progressing towards CT adoption via Precerts, and then, after adoption, if there are any policy or compliance issues that can be signaled back to the CA.


Doug Beattie

unread,
Mar 2, 2018, 3:08:08 PM3/2/18
to rsl...@chromium.org, Certificate Transparency Policy
On Fri, Mar 2, 2018 at 11:01 AM, Ryan Sleevi <rsl...@chromium.org> wrote:


On Fri, Mar 2, 2018 at 8:17 AM, Doug Beattie (Globalsign) <douglas...@gmail.com> wrote:
Hi Devon,

I'm sure this survey will help you understand the readiness of the CAs and the features they are providing to their customers.

As a side note, we recently received a report that some of our SCTs were invalid, and after further research we discovered that the order of SANs and/or Extensions in the issued certificate were not always the same as those in the Precertificate.  We'll be able to resolve this before the April date, but I wonder who else might have some issues with their SCTs and not know it.

That's interesting, we received a question from a CA software vendor regarding that. It would be interesting to know what vendor you use, to know if it is the same.

It probably is the same one given the limited number of CA software vendors.
 
That's a very interesting problem to have manifest, since the ordering of a SEQUENCE is semantically relevant in ASN.1 (that is, SEQUENCE { A, B } is not the same meaning as SEQUENCE { B, A }, even in the case of a SEQUENCE OF). Understanding how this problem manifest would also be useful.

This does highlight the need for greater interoperability testing, although the number of open-source SCT verifiers suggest that there's already ample tooling around this.

We'll be sure to point this out to them and may also include into our pre/post certificate issuance compliance checks

Do you think Google could run a report that lists recently issued certificates with invalid embedded SCTs for public disclosure?  I think this would help reduce the risk of widespread (hopefully not) issues starting in May.

Do you log your certificates post-issuance?

We don't, but if there was a benefit then we can certainly look into posting them to a Google log or two post issuance.
 
Logging your precertificates, and then logging the full certificate (that is, with the SignedCertificateTimestampList), can greatly improve the visibility and diagnostics of the ecosystem. Logging the full certificates post-issuance is something that most CAs should be able to do today, as it does not require integration pre-issuance, and does not require a quorum of logs. While this is not sufficient to meet the CT Qualified definition in and of itself, it can provide valuable information about how the CA is progressing towards CT adoption via Precerts, and then, after adoption, if there are any policy or compliance issues that can be signaled back to the CA.

Google is good at finding certificates in the wild and posting them to CT logs so there are certainly plenty of GlobalSign certificates and corresponding precertificates for some level of analysis.  Does this imply you will be looking to obtain "valuable information" and determining if there are any policy or compliance issues that should be signaled back to the CAs?  That would be very useful.


Ryan Sleevi

unread,
Mar 2, 2018, 3:17:56 PM3/2/18
to Doug Beattie, Ryan Sleevi, Certificate Transparency Policy
On Fri, Mar 2, 2018 at 3:08 PM, Doug Beattie <douglas...@gmail.com> wrote:


On Fri, Mar 2, 2018 at 11:01 AM, Ryan Sleevi <rsl...@chromium.org> wrote:


On Fri, Mar 2, 2018 at 8:17 AM, Doug Beattie (Globalsign) <douglas...@gmail.com> wrote:
Hi Devon,

I'm sure this survey will help you understand the readiness of the CAs and the features they are providing to their customers.

As a side note, we recently received a report that some of our SCTs were invalid, and after further research we discovered that the order of SANs and/or Extensions in the issued certificate were not always the same as those in the Precertificate.  We'll be able to resolve this before the April date, but I wonder who else might have some issues with their SCTs and not know it.

That's interesting, we received a question from a CA software vendor regarding that. It would be interesting to know what vendor you use, to know if it is the same.

It probably is the same one given the limited number of CA software vendors.
 
That's a very interesting problem to have manifest, since the ordering of a SEQUENCE is semantically relevant in ASN.1 (that is, SEQUENCE { A, B } is not the same meaning as SEQUENCE { B, A }, even in the case of a SEQUENCE OF). Understanding how this problem manifest would also be useful.

This does highlight the need for greater interoperability testing, although the number of open-source SCT verifiers suggest that there's already ample tooling around this.

We'll be sure to point this out to them and may also include into our pre/post certificate issuance compliance checks

Do you think Google could run a report that lists recently issued certificates with invalid embedded SCTs for public disclosure?  I think this would help reduce the risk of widespread (hopefully not) issues starting in May.

Do you log your certificates post-issuance?

We don't, but if there was a benefit then we can certainly look into posting them to a Google log or two post issuance.

We would definitely encourage this - of all CAs.

For example, in the discussions around the risk of total log disqualification (e.g. all logs embedded in a certificate are disqualified), logging post-issuance allows for detection of that situation and thus proactive consideration and notification. The Precertificate can be logged to any log, by anyone, including after issuance, so simply seeing a given Precertificate in N logs does not necessarily mean that the full certificate contained N SCTs, or contained the SCTs from those logs.

Logging your precertificates, and then logging the full certificate (that is, with the SignedCertificateTimestampList), can greatly improve the visibility and diagnostics of the ecosystem. Logging the full certificates post-issuance is something that most CAs should be able to do today, as it does not require integration pre-issuance, and does not require a quorum of logs. While this is not sufficient to meet the CT Qualified definition in and of itself, it can provide valuable information about how the CA is progressing towards CT adoption via Precerts, and then, after adoption, if there are any policy or compliance issues that can be signaled back to the CA.

Google is good at finding certificates in the wild and posting them to CT logs so there are certainly plenty of GlobalSign certificates and corresponding precertificates for some level of analysis.  Does this imply you will be looking to obtain "valuable information" and determining if there are any policy or compliance issues that should be signaled back to the CAs?  That would be very useful.

For example, if CAs were actively logging post-issuance (in addition to embedding SCTs), the community could provide feedback as to how well the CA is adopting logging - for example, it might be that one intermediate is not logging and the CA was (unfortunately) unaware of this, prior to the CT requirement. Or it can detect the situations such as you described - where the SCT doesn't match the issued full certificate. Or the issue I mentioned - where the impact of a log disqualification can be discerned.

While Google does disclose the certificates it finds that chain to publicly trusted CAs, as part of the normal web crawling, there can be a variety of delays in that - such as Google not crawling that site that frequently (such as the content not changing often) or delays in the processing and logging pipeline from when a site is crawled to when it's logged (since all of these are batch processes, not necessarily streaming processes).
Reply all
Reply to author
Forward
0 new messages