Full Report
Posted by Chrome Root Program, Chrome Security Team Note: Google Chrome communicated its removal of default trust of Chunghwa Telecom and Netlock in the public forum on May 30, 2025. The Chrome Root Program Policy states that Certification Authority (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. Chrome's confidence in the reliability of Chunghwa Telecom and Netlock as CA Owners included in the Chrome Root Store has diminished due to patterns of concerning behavior observed over the past year. These patterns represent a loss of integrity and fall short of expectations, eroding trust in these CA Owners as publicly-trusted certificate issuers trusted by default in Chrome. To safeguard Chrome’s users, and preserve the integrity of the Chrome Root Store, we are taking the following action. Upcoming change in Chrome 139 and higher: Transport Layer Security (TLS) server authentication certificates validating to the following root CA certificates whose earliest Signed Certificate Timestamp (SCT) is dated after July 31, 2025 11:59:59 PM UTC, will no longer be trusted by default. OU=ePKI Root Certification Authority,O=Chunghwa Telecom Co., Ltd.,C=TW CN=HiPKI Root CA - G1,O=Chunghwa Telecom Co., Ltd.,C=TW CN=NetLock Arany (Class Gold) Főtanúsítvány,OU=Tanúsítványkiadók (Certification Services),O=NetLock Kft.,L=Budapest,C=HU TLS server authentication certificates validating to the above set of roots whose earliest SCT is on or before July 31, 2025 11:59:59 PM UTC, will be unaffected by this change. This approach attempts to minimize disruption to existing subscribers using a previously announced Chrome feature to remove default trust based on the SCTs in certificates. 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? 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 Forum TLS Baseline Requirements. Over the past several months and 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, continued public trust is no longer justified. When will this action happen? The action of Chrome, by default, no longer trusting new TLS certificates issued by these CAs will begin on approximately August 1, 2025, affecting certificates issued at that point or later. This action will occur in Versions of Chrome 139 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 from Chunghwa Telecom or Netlock issued after July 31, 2025 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 action 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 “Chunghwa Telecom" , “行政院” , “NETLOCK Ltd.”, or “NETLOCK Kft.” Website owner action is required, if the “Organization (O)” field listed beneath the “Issued By" heading contains “Chunghwa Telecom" , “行政院” , “NETLOCK Ltd.”, or “NETLOCK Kft.” 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 July 31, 2025. While website operators could delay the impact of blocking action by choosing to collect and install a new TLS certificate issued from Chunghwa Telecom or Netlock before Chrome’s blocking action begins on August 1, 2025, 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 that allows administrators and power users to simulate the effect of an SCTNotAfter distrust constraint as described in this blog post. 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 Learn more about command-line flags here. I use affected 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 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 use this enterprise policy or defer to platform provider guidance for trusting root CA certificates. What about other Google products? Other Google product team updates may be made available in the future.
Analysis Summary
# Industry News: Chrome Outlines Upcoming Changes to Digital Certificate Root Store Management
## Summary
Google is announcing forthcoming structural changes to how the Chrome Root Store is managed to significantly enhance digital certificate security and streamline trust establishment. These updates are likely intended to increase the velocity of security improvements and address evolving threats in the PKI ecosystem.
## Key Details
- Date: May 30, 2025 (as per the blog post date)
- Companies Involved: Google (Chrome)
- Category: Product Update/Platform Policy Change
## The Story
Google has detailed upcoming modifications to the management and structure of the Chrome Root Store, which dictates which Certificate Authorities (CAs) and root certificates are trusted by the Chrome browser. While the specific technical details of the changes are not fully expanded in the provided context, the intent is clearly focused on "Sustaining Digital Certificate Security." In the broader context of web security, changes to browser root stores often involve tighter controls over CA compliance, updating trust policies, or potentially modularizing the store to allow faster updates outside of full browser releases.
## Business Impact
### For the Companies Involved (Google)
- **Reinforcement of Authority:** Google further solidifies its role as a primary gatekeeper of internet trust infrastructure, leveraging its massive browser market share to enforce security standards globally.
- **Operational Efficiency:** Future changes will likely aim to make the root store vetting and update process more efficient, minimizing the risk of long-term security vulnerabilities stemming from outdated trust anchors.
### For Competitors (Mozilla, Apple, Microsoft)
- **Setting the Pace:** Google's proactive moves often force competitors to align or differentiate their own trust management strategies. If Chrome adopts a faster, more rigorous update mechanism, other browser vendors may face pressure to keep pace, particularly regarding newly identified threats or CA performance issues.
- **Interoperability Concerns:** Increased divergence in root store policies across browsers could lead to minor interoperability challenges for relying parties that cater to a multi-browser environment.
### For Customers (Website Owners & End Users)
- **Increased Trustworthiness:** End users benefit from a constantly hardened trust environment, reducing the risk of connection interception or fraudulent site access due to potentially compromised CAs.
- **Operational Risk for Organizations:** Organizations relying on internal CAs or lesser-known public CAs must closely monitor Google's implementation details to ensure their certificates remain valid and trusted by Chrome users. Failure to adapt to potential new requirements could result in widespread browser trust errors.
### For the Market
- **PKI Ecosystem Scrutiny:** The announcement signals continued high-level scrutiny on Public Key Infrastructure (PKI) providers. CAs will need to ensure their compliance and operational security meet the increasingly strict benchmarks set by major platform owners.
- **Standardization Pressure:** This drives further alignment toward modern, robust certificate standards and potentially accelerates the deprecation of older, less secure cryptographic practices.
## Technical Implications
This move strongly suggests adjustments to the mechanisms governing root certificate acceptance, renewal, or revocation within Chrome. This could involve shifting towards more specialized or separated trust stores, perhaps integrating more closely with mechanisms like Certificate Transparency (CT) logs or more stringent hardware security validations for CA operations.
## Strategic Analysis
- **Market Positioning:** Google is leveraging its dominant position in the browser market to dictate security best practices for web infrastructure, positioning Chrome as the leading agent for securing the public web.
- **Competitive Advantage:** By controlling the root store ecosystem, Google creates a significant moat. Any service or CA that fails to meet Chrome's evolving standards effectively loses access to a massive portion of the internet population.
- **Challenges:** The primary challenge is managing the complexity of updating a foundational security component across billions of devices without causing widespread service disruption (i.e., "breaking the internet" for specific sites). Clear communication and long transition timelines will be crucial.
## Industry Reactions
*Analyst opinions are pending full technical disclosure, but the initial reaction is likely positive regarding the intent.* Experts will focus on the scope: Will this involve adding stricter checks for things like key length or signature algorithms, or will it revolutionize how trust is *managed* (e.g., enabling faster delisting)?
## Future Outlook
We should expect detailed technical specifications to follow soon after this announcement, outlining specific timelines for implementation (e.g., Chrome versions) and outlining the new criteria CAs must satisfy. Further communication regarding transitional support for existing CAs is paramount.
## For Security Professionals
Security teams must proactively incorporate monitoring of Google's security blog for the detailed technical specifications. They need to review their reliance on any third-party CAs that might not be in the immediate orbit of major, established players, as non-compliant CAs face immediate trust erosion within the Chrome ecosystem. This is a mandate to maintain strict oversight of certificate lifecycle management.