委托证书不信任

委托证书不信任
Entrust Certificate Distrust

原始链接: https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html

在这篇博文中，Google 的 Chrome 安全团队宣布出于对某些 Entrust 和 AffirmTrust 证书安全实践的担忧，更改其信任设置。这些证书之前在 Chrome 中默认受信任，但从 Chrome 版本 127 开始，这些机构在 2024 年 10 月 31 日之后颁发的任何证书将不再受信任，除非在平台级别明确受信任。这意味着在上述日期之后使用此类证书的网站将在 Chrome 中触发全页插页式警告。但是，使用 2024 年 10 月 31 日之前颁发的证书的网站将不受影响。为了帮助管理员和开发人员测试这些更改的潜在影响，Google 提供了一个测试标志“--test-crs-constraints”，它可以模拟指定的信任锚证书列表和纪元时间戳的 SCTNotAfter 不信任约束。用户可以使用此标志来检查其网站在遇到不可信证书时的行为。在内部网络中使用 Entrust 证书的企业仍然可以通过在 Chrome 运行的特定平台上安装相应的根 CA 证书作为本地受信任的根来信任它们。应根据相关平台提供商的规定，遵循将 CA 添加为本地受信任的指南。此更改适用于所有主要操作系统，但 Apple 政策禁止在 iOS 版 Chrome 中使用该更改。其他 Google 产品将来可能会收到相关更新。 Chrome 安全团队强调，目标是维护安全的网络环境，同时保持透明度并与证书颁发机构合作，以促进持续改进。

Ensurets 是一家领先的证书颁发机构 (CA)，由于过去的证书管理错误，它面临着主要 Web 浏览器的信任问题。出现了三种可能的情况：首先，根程序继续无限期地信任 Ensurets，无需更改；其次，他们在一段时间内容忍问题，最终加剧了不信任；第三，信任的立即撤销促使Ensurets纠正内部缺陷。讨论围绕着表明未来缺陷的历史模式展开，需要采取果断行动。 Ensurets 承认 Google Chrome 即将对某些公共根产生不信任，并向客户保证，尽管这些根失去了信任，但他们的证书仍然安全。然而，这种情况凸显了遵守行业标准并及时解决缺陷的重要性。

原文

3. Evaluate the effects of the flag with test websites

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.

--test-crs-constraints=02ED0EB28C14DA45165C566791700D6451D7FB56F0B2AB1D3B8EB070E56EDFF5, 43DF5774B03E7FEF5FE40D931A7BEDF1BB2E6B42738C4E6D3841103D3AA7F339, 6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177, 73C176434F1BC6D5ADF45B0E76E727287C8DE57616C1E6E6141A2B2CBC7D8E4C, DB3517D1F6732A2D5AB97C533EC70779EE3270A62FB4AC4238372460E6F01E88, 0376AB1D54C5F9803CE4B2E201A0EE7EEF7B57B636E8A93C9B8D4860C96F5FA7, 0A81EC5A929777F145904AF38D5D509F66B5E2C58FCDB531058B0E17F3F0B41B, 70A73F7F376B60074248904534B11482D5BF0E698ECC498DF52577EBF2E93B9A, BD71FDF6DA97E4CF62D1647ADD2581B07D79ADF8397EB4ECBA9C5E8488821423 :sctnotafter=1714521599

Illustrative Command (on Windows):

"C:\Users\User123\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --test-crs-constraints=02ED0EB28C14DA45165C566791700D6451D7FB56F0B2AB1D3B8EB070E56EDFF5,43DF5774B03E7FEF5FE40D931A7BEDF1BB2E6B42738C4E6D3841103D3AA7F339,6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177,73C176434F1BC6D5ADF45B0E76E727287C8DE57616C1E6E6141A2B2CBC7D8E4C,DB3517D1F6732A2D5AB97C533EC70779EE3270A62FB4AC4238372460E6F01E88,0376AB1D54C5F9803CE4B2E201A0EE7EEF7B57B636E8A93C9B8D4860C96F5FA7,0A81EC5A929777F145904AF38D5D509F66B5E2C58FCDB531058B0E17F3F0B41B,70A73F7F376B60074248904534B11482D5BF0E698ECC498DF52577EBF2E93B9A,BD71FDF6DA97E4CF62D1647ADD2581B07D79ADF8397EB4ECBA9C5E8488821423:sctnotafter=1714521599

Illustrative Command (on macOS):

"/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary" --test-crs-constraints=02ED0EB28C14DA45165C566791700D6451D7FB56F0B2AB1D3B8EB070E56EDFF5,43DF5774B03E7FEF5FE40D931A7BEDF1BB2E6B42738C4E6D3841103D3AA7F339,6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177,73C176434F1BC6D5ADF45B0E76E727287C8DE57616C1E6E6141A2B2CBC7D8E4C,DB3517D1F6732A2D5AB97C533EC70779EE3270A62FB4AC4238372460E6F01E88,0376AB1D54C5F9803CE4B2E201A0EE7EEF7B57B636E8A93C9B8D4860C96F5FA7,0A81EC5A929777F145904AF38D5D509F66B5E2C58FCDB531058B0E17F3F0B41B,70A73F7F376B60074248904534B11482D5BF0E698ECC498DF52577EBF2E93B9A,BD71FDF6DA97E4CF62D1647ADD2581B07D79ADF8397EB4ECBA9C5E8488821423:sctnotafter=1714521599

Note: If copy and pasting the above commands, ensure no line-breaks are introduced.

Learn more about command-line flags here.

I use Entrust certificates for my internal enterprise network, do I need to do anything?

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 (e.g., installed in the Microsoft Certificate Store as a Trusted Root CA).

How do enterprises add a CA as locally-trusted?

Customer organizations should defer to platform provider guidance.

What about other Google products?

Other Google product team updates may be made available in the future.

Posted by Chrome Root Program, Chrome Security Team 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. It also describes many of the factors we consider significant when CA Owners disclose and respond to incidents. When things don’t go right, we expect CA Owners to commit to meaningful and demonstrable change resulting in evidenced continuous improvement. Over the past several years, publicly disclosed incident reports highlighted a pattern of concerning behaviors by Entrust that fall short of the above expectations, and has eroded confidence in their competence, reliability, and integrity as a publicly-trusted CA Owner. In response to the above concerns and to preserve the integrity of the Web PKI ecosystem, Chrome will take the following actions. Upcoming change in Chrome 127 and higher:

TLS server authentication certificates validating to the following Entrust roots whose earliest Signed Certificate Timestamp (SCT) is dated after October 31, 2024, will no longer be trusted by default.

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.

feature Additionally, 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 (e.g., explicit trust is conveyed through a Group Policy Object on Windows), the SCT-based constraints described above will be overridden and certificates will function as they do today. To further minimize risk of disruption, website operators are encouraged to review the “Frequently Asked Questions" listed below. Why is Chrome taking action? Certification Authorities (CAs) serve a privileged and trusted role on the Internet that underpin encrypted connections between browsers and websites. With this tremendous responsibility comes an expectation of adhering to reasonable and consensus-driven security and compliance expectations, including those defined by the CA/Browser TLS Baseline Requirements. Over the past six years, we have observed a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports. 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. When will this action happen? 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. Apple policies prevent the Chrome Certificate Verifier and corresponding Chrome Root Store from being used on Chrome for iOS. What is the user impact of this action? 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. How can a website operator tell if their website is affected? Website operators can determine if they are affected by this issue by using the Chrome Certificate Viewer. Use the Chrome Certificate Viewer

Navigate to a website (e.g., https://www.google.com)

Click the “Tune" icon

Click “Connection is Secure"

Click “Certificate is Valid" (the Chrome Certificate Viewer will open)

Website owner action is not required, if the “Organization (O)” field listed beneath the “Issued By" heading does not contain “Entrust" or “AffirmTrust”.
Website owner action is required, if the “Organization (O)” field listed beneath the “Issued By" heading contains “Entrust" or “AffirmTrust”.

What does an affected website operator do? We recommend that affected website operators transition to a new publicly-trusted CA Owner as soon as reasonably possible. 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. Can I test these changes before they take effect? Yes. A command-line flag was added beginning in Chrome 128 (available in Canary/Dev at the time of this post’s publication) 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 distrust1. Close all open versions of Chrome2. Start Chrome using the following command-line flag, substituting variables described below with actual values --test-crs-constraints=$[Comma Separated List of Trust Anchor Certificate SHA256 Hashes]:sctnotafter=$[epoch_timestamp] 3. Evaluate the effects of the flag with test websites 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. --test-crs-constraints=02ED0EB28C14DA45165C566791700D6451D7FB56F0B2AB1D3B8EB070E56EDFF5, 43DF5774B03E7FEF5FE40D931A7BEDF1BB2E6B42738C4E6D3841103D3AA7F339, 6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177, 73C176434F1BC6D5ADF45B0E76E727287C8DE57616C1E6E6141A2B2CBC7D8E4C, DB3517D1F6732A2D5AB97C533EC70779EE3270A62FB4AC4238372460E6F01E88, 0376AB1D54C5F9803CE4B2E201A0EE7EEF7B57B636E8A93C9B8D4860C96F5FA7, 0A81EC5A929777F145904AF38D5D509F66B5E2C58FCDB531058B0E17F3F0B41B, 70A73F7F376B60074248904534B11482D5BF0E698ECC498DF52577EBF2E93B9A, BD71FDF6DA97E4CF62D1647ADD2581B07D79ADF8397EB4ECBA9C5E8488821423 :sctnotafter=1714521599 Illustrative Command (on Windows): "C:\Users\User123\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --test-crs-constraints=02ED0EB28C14DA45165C566791700D6451D7FB56F0B2AB1D3B8EB070E56EDFF5,43DF5774B03E7FEF5FE40D931A7BEDF1BB2E6B42738C4E6D3841103D3AA7F339,6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177,73C176434F1BC6D5ADF45B0E76E727287C8DE57616C1E6E6141A2B2CBC7D8E4C,DB3517D1F6732A2D5AB97C533EC70779EE3270A62FB4AC4238372460E6F01E88,0376AB1D54C5F9803CE4B2E201A0EE7EEF7B57B636E8A93C9B8D4860C96F5FA7,0A81EC5A929777F145904AF38D5D509F66B5E2C58FCDB531058B0E17F3F0B41B,70A73F7F376B60074248904534B11482D5BF0E698ECC498DF52577EBF2E93B9A,BD71FDF6DA97E4CF62D1647ADD2581B07D79ADF8397EB4ECBA9C5E8488821423:sctnotafter=1714521599 Illustrative Command (on macOS): "/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary" --test-crs-constraints=02ED0EB28C14DA45165C566791700D6451D7FB56F0B2AB1D3B8EB070E56EDFF5,43DF5774B03E7FEF5FE40D931A7BEDF1BB2E6B42738C4E6D3841103D3AA7F339,6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177,73C176434F1BC6D5ADF45B0E76E727287C8DE57616C1E6E6141A2B2CBC7D8E4C,DB3517D1F6732A2D5AB97C533EC70779EE3270A62FB4AC4238372460E6F01E88,0376AB1D54C5F9803CE4B2E201A0EE7EEF7B57B636E8A93C9B8D4860C96F5FA7,0A81EC5A929777F145904AF38D5D509F66B5E2C58FCDB531058B0E17F3F0B41B,70A73F7F376B60074248904534B11482D5BF0E698ECC498DF52577EBF2E93B9A,BD71FDF6DA97E4CF62D1647ADD2581B07D79ADF8397EB4ECBA9C5E8488821423:sctnotafter=1714521599 Note: If copy and pasting the above commands, ensure no line-breaks are introduced. Learn more about command-line flags here. I use Entrust certificates for my internal enterprise network, do I need to do anything? 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 (e.g., installed in the Microsoft Certificate Store as a Trusted Root CA). How do enterprises add a CA as locally-trusted? Customer organizations should defer to platform provider guidance. What about other Google products? Other Google product team updates may be made available in the future.