Chrome Removes Trust from Chunghwa Telecom and Netlock

Google Chrome has announced that, effective July 31, its browser will no longer trust any TLS certificates issued by two long-standing certificate authorities (CAs): Taiwan’s Chunghwa Telecom and Hungary’s Netlock. This decision follows a year-long pattern of compliance violations, misissuances, and an overall failure to meet the stringent requirements set by the Chrome Root Store Policy and the CAB Forum’s Baseline Requirements. For enterprises, developers, and end users, the move underscores the criticality of robust certificate lifecycle management and transparent CA governance.

In practical terms, websites using certificates from these CAs will present a full-page security warning in Chrome, urging visitors to proceed with caution or abandon the connection altogether. Organizations still relying on these providers must migrate to alternative, policy-compliant CAs or risk service outages, degraded SEO rankings, and the erosion of user trust.

Overview of the Revocation

Chunghwa Telecom and Netlock have been entrenched members of the browser root bundles for many years, trusted to mint X.509 certificates signed by root keys recognized in both Chrome’s and other major browsers’ stores. Certificates anchored in these roots facilitate HTTPS connections, enable OCSP stapling, and log every issuance to public Certificate Transparency (CT) logs—mechanisms designed to prevent undetected misissuance and man-in-the-middle attacks.

Despite this, Google’s Chrome Security Team cited “patterns of concerning behavior” spanning several policy areas: failure to disclose intermediate CA certificates in the Common CA Database (CCADB), delayed revocation of misissued certificates, and disregarded reporting timelines during critical security incidents. With the Chrome Root Program’s zero-tolerance stance on repeated or severe infractions, the cumulative risk these CAs posed could no longer be justified.

Patterns of Concerning Behavior and Technical Lapses

• Netlock omitted an intermediate CA certificate from CCADB for over 12 months, contravening Mozilla’s CA Certificate Policy transparency requirements.
• Netlock failed to revoke a misissued certificate despite a 72-hour notification window mandated by the CAB Forum Baseline Requirements v1.8.1.
• Chunghwa Telecom misissued 247 certificates with malformed subjectAltName entries, breaking RFC 5280 naming syntax.
• Repeated delays in OCSP responder updates left clients without valid revocation status data for critical periods.
• Both CAs missed multiple weekly reporting deadlines following public disclosure of security incidents, undermining remediation verification.

Chrome Root Program Requirements

The Chrome Root Store Policy outlines a multi-tier audit and incident response framework. Key requirements include:

1. Quarterly WebTrust or ETSI audits attesting to policy compliance and operational security.
2. Mandatory logging of all issued certificates in at least two independent CT logs, with cross-log consistency proofs.
3. Automated OCSP or CRL distribution points updated within 24 hours of any revocation event.
4. Immediate notification to major browsers and the CCADB upon detection of any misissuance or key compromise.

“When these factors are considered in aggregate and measured against the inherent risk each publicly-trusted CA poses, continued public trust is no longer justified,” the Chrome team warned in its June security bulletin.

Implications for Enterprises and Developers

Organizations using Chunghwa Telecom or Netlock certificates should begin migration immediately. The disruption window closes on July 31 when Chrome 122 (or later) will enforce the distrust. Automated certificate management platforms—leveraging the ACME protocol or enterprise PKI integrations—can streamline the transition to alternative CAs such as Let’s Encrypt, DigiCert, or Sectigo, all of which maintain spotless CT log records and audit histories.

Developers must also update CI/CD pipelines to validate CA root bundles, implement CT log monitoring, and add fallback OCSP stapling checks. Teams relying on intermediate certificates should verify their inclusion in CCADB and test revocation responses under simulated misissuance scenarios to ensure compliance with both policy and real-world incident requirements.

Technical Breakdown of CA Compliance Audits

WebTrust and ETSI audits drill into a CA’s cryptographic key management, physical protection of Hardware Security Modules (HSMs), software change control, and incident response maturity. Auditors verify that:

• Root and intermediate private keys are split across multi-party HSMs with threshold signing policies.
• Certificate issuance systems enforce strict validation of domain control according to RFC 8555 (ACME) or equivalent protocols.
• Logging and monitoring tools capture every certificate request, approval step, and issuance event in immutable logs.

Failures in any of these areas reflect gaps that attackers could exploit to mint rogue certificates, intercept encrypted traffic, or perform widespread phishing campaigns undetected.

Future Outlook and Industry Trends

Google’s decisive action signals a broader industry shift toward stricter root program governance and real-time compliance verification. Upcoming browser releases will likely tighten CT log enforcement, deprecate SHA-1 and even SHA-2 where necessary, and mandate DNS-based Authentication of Named Entities (DANE) support for additional validation layers.

Industry experts anticipate more frequent distrust events as audit cycles reveal legacy CAs unable or unwilling to meet escalating security standards. Enterprises and cloud providers should monitor root program updates across Chrome, Firefox, and Microsoft Edge to anticipate and prepare for any further changes in the digital certificate ecosystem.