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.
ESET researchers have discovered a vulnerability that allows bypassing UEFI Secure Boot, affecting the majority of UEFI-based systems. This vulnerability, assigned CVE-2024-7344, was found in a UEFI application signed by Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate. Exploitation of this vulnerability leads to the execution of untrusted code during system boot, enabling potential attackers to easily deploy malicious UEFI bootkits (such as Bootkitty or BlackLotus) even on systems with UEFI Secure Boot enabled, regardless of the installed operating system.
DigiCert will be revoking certificates that did not have proper Domain Control Verification (DCV). Before issuing a certificate to a customer, DigiCert validates the customer’s control or ownership over the domain name for which they are requesting a certificate using one of several methods approved by the CA/Browser Forum (CABF). One of these methods relies on the customer adding a DNS CNAME record which includes a random value provided to them by DigiCert. DigiCert then does a DNS lookup for the domain and verifies the same random value, thereby proving domain control by the customer..
Let’s Encrypt is proud to introduce Sunlight, a new implementation of a Certificate Transparency log that we built from the ground up with modern Web PKI opportunities and constraints in mind. In partnership with Filippo Valsorda, who led the design and implementation, we incorporated feedback from the broader transparency logging community, including the Chrome and TrustFabric teams at Google, the Sigsum project, and other CT log and monitor operators. Their insights have been instrumental in shaping the project’s direction.