Certificate Transparency Enforcement in Google Chrome
Devon O'Brien
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
[8] https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy
Weitsong 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)
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
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 Beattie
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.
Ryan Sleevi
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 checksDo 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.