The Chrome Security Team prioritizes the security and privacy of Chrome's users, and we are unwilling to compromise on these values.
The Chrome Root Program Policy states that CA certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion.
In response to the above concerns and to preserve the integrity of the Web PKI ecosystem, Chrome will take the following actions.
TLS server authentication certificates validating to the following Entrust roots whose earliest Signed Certificate Timestamp is dated after October 31, 2024, will no longer be trusted by default.
Entrust.net/legal-terms+OU=(c) 2015 Entrust, Inc. - for authorized use only,O=Entrust, Inc.,C=US CN=AffirmTrust Commercial,O=AffirmTrust,C=US CN=AffirmTrust Networking,O=AffirmTrust,C=US CN=AffirmTrust Premium,O=AffirmTrust,C=US CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US TLS server authentication certificates validating to the above set of roots whose earliest SCT is on or before October 31, 2024, will be unaffected by this change.
This approach attempts to minimize disruption to existing subscribers using a recently announced Chrome feature to remove default trust based on the SCTs in certificates.
Should a Chrome user or enterprise explicitly trust any of the above certificates on a platform and version of Chrome relying on the Chrome Root Store, the SCT-based constraints described above will be overridden and certificates will function as they do today.
When these factors are considered in aggregate and considered against the inherent risk each publicly-trusted CA poses to the Internet ecosystem, it is our opinion that Chrome's continued trust in Entrust is no longer justified.
Blocking action will begin on approximately November 1, 2024, affecting certificates issued at that point or later.
Blocking action will occur in Versions of Chrome 127 and greater on Windows, macOS, ChromeOS, Android, and Linux.
By default, Chrome users in the above populations who navigate to a website serving a certificate issued by Entrust or AffirmTrust after October 31, 2024 will see a full page interstitial similar to this one.
Certificates issued by other CAs are not impacted by this action.
Website operators can determine if they are affected by this issue by using the Chrome Certificate Viewer.
To avoid adverse website user impact, action must be completed before the existing certificate(s) expire if expiry is planned to take place after October 31, 2024.
While website operators could delay the impact of blocking action by choosing to collect and install a new TLS certificate issued from Entrust before Chrome's blocking action begins on November 1, 2024, website operators will inevitably need to collect and install a new TLS certificate from one of the many other CAs included in the Chrome Root Store.
A command-line flag was added beginning in Chrome 128 that allows administrators and power users to simulate the effect of an SCTNotAfter distrust constraint as described in this blog post FAQ. How to: Simulate an SCTNotAfter distrust.
Start Chrome using the following command-line flag, substituting variables described below with actual values.
Example: The following command will simulate an SCTNotAfter distrust with an effective date of April 30, 2024 11:59:59 PM GMT for all of the Entrust trust anchors included in the Chrome Root Store.
The expected behavior is that any website whose certificate is issued before the enforcement date/timestamp will function in Chrome, and all issued after will display an interstitial.
Beginning in Chrome 127, enterprises can override Chrome Root Store constraints like those described for Entrust in this blog post by installing the corresponding root CA certificate as a locally-trusted root on the platform Chrome is running.
This Cyber News was published on security.googleblog.com. Publication date: Sat, 29 Jun 2024 17:13:05 +0000