Web PKI CA Distrust History and Timeline - Who Removed Trust, on What Grounds, and by Which Mechanism

First Published: 2026-10-29
Last Updated: 2026-10-29

Browser and operating system root programs may remove trust in a Certificate Authority (CA), but this does not necessarily mean that all certificates issued by that CA become unusable immediately. The validity of each certificate depends on how the root program chooses to remove trust. If a root certificate is removed from the root store, devices receiving that update will no longer trust certificates whose chain of trust ends with that root. Conversely, if trust is cut off on a specific date, certificates issued before that date will continue to be trusted until their individual expiration dates. The cutoff can use the certificate's issuance date or a Certificate Transparency timestamp.

This article presents a timeline of CA distrust, from DigiNotar in 2011 to eMudhra in 2026. It focuses on four root programs: Chrome, Mozilla, Apple, and Microsoft. Each row details which root program removed trust from which CA, on what date, using what method, and includes the wording provided by the operator. Dates are differentiated to indicate announcement dates, effective dates, cutoff dates, dates when the incident was reported, and version numbers. Rows that could not be found in the primary sources of the four root programs have been omitted and listed separately, along with the scope of the search. Discrepancies in the source materials are presented as they appear.

This article does not evaluate CAs or root programs. The reasons for removing trust are based on the wording provided by each operator. It does not discuss pricing. The information presented was verified as of October 29, 2026.

Related articles on this site:

Background and Method of Creating the Web PKI CA Distrust Timeline

When a Certificate Authority (CA) is removed, those responsible for managing certificates typically want to know three things: How long can their certificates continue to be used? Which root programs removed the CA, and by what method? Where is this information documented, and where is it not? Each root program writes these answers in a different place and in a different form. The purpose of this article is to simply list these answers based solely on the text found in primary source documents.

The intended audience for this article includes those responsible for products with TLS trust stores, those involved in selecting CAs, and certificate managers. Specifically, this article is written for readers who hold one of the following assumptions:

When a browser removes a CA, all certificates issued by that CA become unusable from that day forward.
Only Chrome removes CAs.
The reason CAs are removed is always due to a key compromise.
"Revoke" and "distrust" are the same thing.

The first and fourth assumptions are not universally true and depend on the specific method and timing of the removal. Regarding the second assumption, the rows of the timeline show that Chrome, Mozilla, Apple, and Microsoft have each removed trust in CAs. However, there are some combinations for which documentation could not be found. Regarding the third assumption, the only instance where the operator explicitly cited a key compromise as the reason for removal is in the row for eMudhra in 2026. For earlier rows, the reasons appear in the section "What the Programs Gave as Grounds," based on the operators' statements.

Sources Used in This Article

The entries in the timeline are primarily drawn from the following resources:

Chrome — The Google Online Security Blog, along with announcements on blog.google/security/, where the blog redirects from 2025, Chrome Root Program Policy version 1.8 (last updated 2026-02-05) and the Policy Archive, the Chrome Root Store definition files and the blocklist README in the Chromium source code, and Chrome Root Program posts on the Mozilla dev-security-policy forum.
Mozilla — The Mozilla Security Blog, Mozilla Root Store Policy version 3.1 (effective 2026-07-01), the CA/Additional_Trust_Changes page on the Mozilla wiki, the CCADB removal and inclusion lists (in CSV format), Bugzilla, NSS release notes, and posts on the dev-security-policy forum.
Apple — Apple's support pages. Page 121668, titled "Changes to Certification Authorities and certificates," shows a Published Date of 2024-11-15. Page 149555 shows a Published Date of 2026-10-23. In addition to pages 121668 and 149555 (regarding eMudhra), there are individual pages for Symantec, TrustCor, WoSign, and DigiNotar.
Microsoft — Microsoft Security Advisory, Microsoft Trusted Root Program monthly notices and an index of release notes, the Announcements.md file in the Trusted Root Program's GitHub repository, and the Microsoft Security Response Center (MSRC) blog.

This article cites announcements and policies separately. Announcements are found in blogs and posts, describing specific events and reflecting decisions made at that time. Policies, such as the Chrome Root Program Policy and the Mozilla Root Store Policy, outline rules applicable to any event. When the main text quotes a document, it names the document (announcement or policy).

The dev-security-policy forum is hosted on Google Groups, and the page is rendered using JavaScript. This article consulted copies from the Internet Archive to read the content and dates of the posts. The time zone of the displayed post time is not stated; rows where the date may differ by one day in UTC say so. Copies from the Mozilla Security Blog articles between 2011 and 2018 were also checked on the Internet Archive.

⚠ The page for Apple's 121668 still displays a "Published Date" of 2024-11-15. At the check date, it had no rows from 2025 or later. Information regarding eMudhra can be found on a separate page, 149555. ⚠ The index for Microsoft's release notes is currently only available up to the announcement from September 2025. Announcements from 2026 are in the Announcements.md file in the Trusted Root Program's GitHub repository.

Which Events Become Rows

The events included as rows in the timeline must satisfy both of the following conditions:

The root program removed or restricted a CA's TLS trust, or blocked it with a list that it distributes.
The root program's own primary documentation explicitly states that this action was taken.

A CA's own planned retirement of a root is not included as a row. For example, the CCADB removal list notes, for the removal of Chunghwa Telecom's ePKI root, that the CA decided to retire it. Mozilla's Bugzilla contains bugs related to eMudhra's emSign Root CA - C1 and emSign ECC Root CA - C3, where eMudhra itself requested their removal. The CCADB removal list also gives the removal of Entrust's root due to an expiring certificate. None of these instances represent a decision by the root program to remove trust, so they are not included as rows. The removal of AffirmTrust's four roots is also excluded, as the CCADB removal list only mentions a change in ownership and does not state the reason for the removal. The removal of Camerfirma's two 2008 roots in NSS version 3.94 is also excluded: Mozilla's Bug 1850982 states that the removal was made at the CA's request, and the two roots then had only the Email trust bit.

Conversely, Chrome's announcement on 2025-05-30 regarding the removal of the default trust for Chunghwa Telecom and Netlock is included as a row. Even for the same CA root, a CA's own retirement and a decision made by the root program are considered separate events.

This timeline does not claim to be comprehensive. The rows listed are limited to events documented in the primary sources reviewed for this article.

Action Words: Revoke, Block, Distrust, Remove, and Constrain

This article uses the following five action words with the following meanings:

Revoke — An action by a Certificate Authority (CA) to invalidate a certificate it has issued. Invalidated certificates are listed in CRLs or OCSP.
Block — An action by the root program to reject specific certificates or keys with a list that it distributes. These lists include Chrome's CRLSet, Mozilla's OneCRL, Apple's certificate configuration data, Windows' Disallowed Certificate Trust List, and blocklists embedded in Chromium's source code.
Distrust — An action by the root program to remove trust from certificates below a root, while leaving the root itself in the root store. This includes removing trust based on usage (such as Mozilla's websites trust bit) and cutting off trust by date.
Remove — An action by the root program to exclude root certificates from the root store.
Constrain — An action by the root program to restrict the names that certificates below a root can use, such as limiting them to top-level domains.

Microsoft documents the distinction between revocation and the root program's own actions. The Trusted Root Program's Announcements.md states, in its 2026-10-26 announcement about eMudhra, the following:

Revocation and removal are distinct actions. Revocation addresses the known affected intermediate CAs; removal
is a broader decision about which certificates Microsoft trusts by default.

The MSRC blog also describes the same event as follows:

Removing a root from a trust list is not the same as revoking the known impacted intermediate certificate
authorities.

⚠ The language used by the operators may differ from the categorization used in this article. This article will retain the operators' original language, but only the timeline's Mechanism column uses this article's categories. There are three instances of such discrepancies.

Chrome refers to its cutoffs by Certificate Transparency date (Entrust, Chunghwa Telecom, and Netlock) as blocking action in its own announcements. This article classifies it as distrust.
Starting in 2011, Mozilla and Microsoft have used the term "revoke" for root program actions; the titles of Mozilla's 2013 posts on TURKTRUST and ANSSI also begin with "Revoking Trust". Mozilla wrote revoke trust about the DigiNotar root, and Microsoft wrote revokes the trust about placing the roots in the Untrusted Certificate Store.
Mozilla describes OneCRL as a central list of revoked certificates. This article classifies rejecting certificates through OneCRL as a block.

Mechanisms

The Mechanism column in the timeline lists one of the following seven options:

Root removal (remove) — Excludes roots from the root store.
TLS trust off (distrust) — Disables TLS trust for certificates below a root, regardless of the issuance date. This corresponds to removing the websites trust bit in Mozilla and aligns with Microsoft's notices regarding Disallow Server Authentication and Disable. This also applies to the final stage (Symantec) when distrust is implemented in phases.
Issuance-date cutoff (distrust) — Does not trust certificates whose issuance date is after the cutoff date. This corresponds to Mozilla's distrust-after, Apple's effective date, and Microsoft's NotBefore. Mozilla's wiki refers to the date being compared as the certificate's "Valid-From" date. Apple and Microsoft's documentation refer to when a certificate was issued, but do not specify which field of the certificate this refers to. The Symantec rows include stages in the reverse direction: Chrome version 66, Firefox version 60, and Apple's 2018-08-01 row do not trust certificates issued before the cutoff date.
SCT-date cutoff (distrust) — Does not trust certificates whose earliest Signed Certificate Timestamp (SCT) date is after the cutoff date. This corresponds to Chrome's SCTNotAfter.
Blocklist (block) — Rejects specific certificates or keys with a list that the root program distributes.
Name constraint (constrain) — Restricts the names that can be used.
Allowlist (distrust) — Does not trust certificates below a root, except for those listed in a designated public list. This corresponds to Chrome's 2015 announcement regarding CNNIC and Apple's CNNIC page.

⚠ Microsoft's NotBefore is the name of an attribute applied to roots within Microsoft's Certificate Trust List. It is a separate entity from the notBefore field in X.509 certificates, despite the identical spelling. Microsoft's February 2025 announcement describes the meaning of this attribute as follows:

Please note that the NotBefore date is set to April 16, 2025. This means only certificates issued after this
date will be distrusted.

Date Types

A single event may have multiple dates. This article uses the Date Type column in the timeline, which will contain one of the following five options:

Announced — The date on which the root program made a public announcement. This includes dates of announcements, postings, and advisories. If an announcement was later revised, the revision date has its own row, marked as a revision.
Effective — The date from which the root program wrote that the action takes effect on devices. This includes dates of initial blocking, releases, and removals.
Cutoff — A cutoff date used to differentiate between certificates that continue to be trusted and those that do not. This is distinct from the date on which the change takes effect.
Incident Reported — The date and time at which the root program received a report of the incident.
Release Tag — The version number for Chrome, Firefox, NSS, and Chrome Root Store, or the name of an Apple security update (Security Update 2011-005). This article does not convert version numbers into dates. A Release Tag row has the version number in the Date column and is placed after the related announcement row.

⚠ Apple's page 121668 refers to its own date as an "effective date." Furthermore, it states that certificates issued on or before that date are expected to continue functioning until their expiration. In this article's classification, Apple's "effective date" corresponds to the Cutoff category. This article quotes Apple's wording verbatim.

The `Where It Is Written` and `No Statement Found` Columns

This series of articles includes two columns at the end of each table. The Where It Is Written column in this article's timeline lists the document behind each row. All documents were verified as of October 29, 2026.

This article puts the No Statement Found column in a separate table, rather than in the timeline itself. The timeline only includes information directly obtained from primary sources. When a statement regarding a specific CA or a particular root program cannot be found, this article does not claim that the program did nothing. Instead, the separate table lists the materials and terms searched.

This article writes the status of the materials with the following four English phrases:

Not found — no statement was found (with details of the search conducted)
Not listed in the documentation — the documentation does not list
The sources disagree — the sources disagree (listing both statements and their sources, without definitively identifying one as incorrect)
Inference — Marked as this article's reading in the text.

What This Article Leaves to Other Articles

The article "TLS Certificate Ecosystem History and Timeline" explains how DigiNotar and Symantec's issues relate to the need for Certificate Transparency. This article lists the rows for the two CAs only as each root program's mechanism. A row in the same article, on the 2026-10-06 hijacks of country-code top-level domain registries, which resulted in Chrome blocking certificates via CRLSets, is not included here because it is not a CA distrust.

The article "Post-Quantum Certificates for Public TLS Are Three Proposals That Disagree" covers the root programs' post-quantum policies. The dates associated with the EKU for client authentication are covered in "When Public Certificates Stop Carrying clientAuth." Regarding the eMudhra incident in 2026, the article in this series, "When Intermediate CA Keys Are Compromised," addresses how each client (Go, Node.js, Python, Java, and AWS services) learns of it and what it should do. "Which Name the CA Validates," also part of this series, discusses the names that CAs validate.

This article does not cover the technical details of the incidents or the methods used in the attacks. It also does not offer recommendations on which CAs to choose.

Web PKI CA Distrust Historical Timeline (Updates from 2011)

The following five tables constitute the main body of this historical timeline. Each table has the following columns:

Date — The date for that row. The Release Tag row indicates the version number.
Date Type — The type of date. Refers to one of the five categories listed above.
Root Program — The root program that performed the action.
CA — The target CA.
Mechanism — The mechanism type. Refers to one of the seven categories listed above.
What the Program Wrote — What the root program recorded. Short phrases are kept in their original form; longer sentences are summarized.
Where It Is Written — The document that provides the basis for the row.

Index:

2011–2015 - Period of root removals and intermediate CA blocks in response to incidents.
2016–2019 - Period of cutoffs by issuance date and staged distrust by version.
2020–2023 - Period of continued removal from the root store, utilizing "distrust-after" and "NotBefore" as mechanisms.
2024–2025 - Period when Chrome cut off trust by SCT date.
2026 - eMudhra

* You can sort the table by clicking on the column name.

2011–2015 — Incident-Driven Removals and Blocks

During the period of 2011–2015, all actions taken were in response to incidents involving the discovery of fraudulently issued certificates. In many of the rows, the root programs either excluded the problematic root certificate or blocked the intermediate Certificate Authority (CA) involved. There are also rows for name constraints (ANSSI, India CCA), a published list (CNNIC), and an issuance-date cutoff (CNNIC).

Date	Date Type	Root Program	CA	Mechanism	What the Program Wrote	Where It Is Written
2011-08-29	`Announced`	Mozilla	DigiNotar	`Root removal`	The program stated that it would remove trust in the DigiNotar root and would soon release new versions, such as Firefox.	Fraudulent *.google.com Certificate (Mozilla Security Blog)
2011-09-02	`Announced`	Mozilla	DigiNotar	`Root removal`	The program stated that it would perform a complete removal from the root program, not just a temporary stop, and would also remove any remaining exceptions for DigiNotar certificates.	DigiNotar Removal Follow Up (Mozilla Security Blog)
2011-09-03	`Announced`	Chrome	DigiNotar	—	In a 2011-09-03 update to the 2011-08-29 announcement, the program stated that it had decided to reject all Certificate Authorities (CAs) operated by DigiNotar. The announcement did not describe the mechanism for rejection.	An update on attempted man-in-the-middle attacks (Google Online Security Blog)
2011-09-13	`Effective`	Microsoft	DigiNotar	`Blocklist`	The program announced an update (KB2616676) that would place DigiNotar's roots in the Microsoft Untrusted Certificate Store. Microsoft describes this action as `revokes the trust`.	Microsoft Security Advisory 2607712
Security Update 2011-005	`Release Tag`	Apple	DigiNotar	`Root removal`	The program stated that it removed DigiNotar from the list of trusted root certificates and from the list of Extended Validation (EV) CAs, and configured default trust settings so that DigiNotar certificates are not trusted. The page did not specify the release date of the update.	About Security Update 2011-005 (Apple Support)
2012-12-25	`Effective`	Chrome	TURKTRUST	`Blocklist`	On December 25, 2012, the program updated the Chrome revocation metadata to block an intermediate CA, and on December 26, 2012, it blocked a second intermediate CA. The announcement was dated January 3, 2013.	Enhancing digital certificate security (Google Online Security Blog)
2013-01-03	`Announced`	Mozilla	TURKTRUST	`Blocklist`	The program stated that it would remove trust in two mis-issued certificates and would distribute the update in Firefox on January 8, 2013. It also stated that the inclusion of one of TURKTRUST's roots was suspended pending review.	Revoking Trust in Two TurkTrust Certificates (Mozilla Security Blog)
2013-01-03	`Announced`	Microsoft	TURKTRUST	`Blocklist`	The program stated that it had marked one certificate that was used in an attack, and two other certificates, as untrusted and added them to the Certificate Trust List.	Microsoft Security Advisory 2798897
2013-12-07	`Announced`	Chrome	ANSSI	`Blocklist`	The program updated Chrome's revocation metadata to block an intermediate CA.	Further improving digital certificate security (Google Online Security Blog)
2013-12-09	`Announced`	Mozilla	ANSSI	`Blocklist`	The program updated Firefox's certificate store so that certificates below the intermediate CA are not trusted.	Revoking Trust in one ANSSI Certificate (Mozilla Security Blog)
2013-12-09	`Announced`	Microsoft	ANSSI	`Blocklist`	The program updated the Certificate Trust List to remove trust in the problematic certificate.	Microsoft Security Advisory 2916652
2013-12-12	`Announced`	Chrome	ANSSI	`Name constraint`	As an update to the announcement from December 7, 2013, the program stated that it had decided to restrict the ANSSI certificate authority to a list of top-level domains in a future version of Chrome.	Further improving digital certificate security (Google Online Security Blog)
2014-07-08	`Announced`	Chrome	India CCA	`Blocklist`	The program wrote that it blocked, with a CRLSet push, certificates issued without authorization from intermediate CAs that India CCA trusts. The program noted that Firefox was not affected, as it did not include this root in its root store.	Maintaining digital certificate security (Google Online Security Blog)
2014-07-09	`Announced`	Chrome	India CCA	`Name constraint`	As an update to the announcement, the program stated that it had decided to limit the India CCA root to a list of domains and their subdomains in a future Chrome release.	Maintaining digital certificate security (Google Online Security Blog)
2014-07-10	`Announced`	Microsoft	India CCA	`Blocklist`	The program updated the Certificate Trust List to reject the problematic certificate.	Microsoft Security Advisory 2982792
2015-03-23	`Announced`	Chrome	CNNIC	`Blocklist`	The program wrote that it blocked, with a CRLSet push, the intermediate CA certificate held by MCS Holdings, with which CNNIC had contracted.	Maintaining digital certificate security (Google Online Security Blog)
2015-04-01	`Announced`	Chrome	CNNIC	`Allowlist`	As an update to the announcement, the program stated that it would no longer recognize CNNIC's root and EV CAs in Google products. It stated that existing certificates would continue to be trusted for a limited time, as listed on a published list.	Maintaining digital certificate security (Google Online Security Blog)
2015-04-02	`Announced`	Mozilla	CNNIC	`Issuance-date cutoff`	The program wrote that it would update its code so that Mozilla products no longer trust CNNIC certificates with a notBefore date on or after April 1, 2015.	Distrusting New CNNIC Certificates (Mozilla Security Blog)
NSS 3.32 / Firefox 56	`Release Tag`	Mozilla	CNNIC	`Root removal`	The CCADB removal list indicated the removal of two CNNIC roots in NSS version 3.32 and Firefox version 56.	Removed CA Certificate Report (CCADB) / Bug 1380868 (Bugzilla)

2016–2019 — Issuance-Date Cutoffs and Staged Distrust

During this period (2016–2019), root programs used cutoffs by certificate issuance date more often. Certificates issued before the cutoff date continued to be trusted for a certain period. For Symantec, Chrome and Mozilla removed trust in stages, by browser version.

Date	Date Type	Root Program	CA	Mechanism	What the Program Wrote	Where It Is Written
2016-10-24	`Announced`	Mozilla	WoSign / StartCom	`Issuance-date cutoff`	The program stated that it would distrust certificates with a notBefore date after October 21, 2016, and noted that this change would be included in the release train for Firefox version 51. It also stated that if further back-dating were discovered, it would immediately and permanently remove trust in the affected roots.	Distrusting New WoSign and StartCom Certificates (Mozilla Security Blog)
2016-10-31	`Announced`	Chrome	WoSign / StartCom	`Issuance-date cutoff`	The program wrote that, starting with Chrome version 56, it would not trust certificates issued after October 21, 2016, at 00:00:00 UTC. Certificates issued before that date might continue to be trusted, subject to certain conditions.	Distrusting WoSign and StartCom Certificates (Google Online Security Blog)
2016-12-01	`Cutoff`	Apple	WoSign / StartCom	`Issuance-date cutoff`	The program stated that it would block certificates from WoSign and StartCom root CAs whose "Not Before" date is on or after December 1, 2016, at 00:00:00 GMT/UTC. It also stated that one of WoSign's intermediate CAs would no longer be trusted. The page does not state the date of this announcement.	Lists of available trusted root certificates in macOS (Apple Support)
NSS 3.34 / Firefox 58	`Release Tag`	Mozilla	WoSign / StartCom	`Root removal`	The CCADB removal list gives the removal of the WoSign and StartCom roots as NSS version 3.34 and Firefox version 58.	Removed CA Certificate Report (CCADB)
2017-09-11	`Announced`	Chrome	Symantec	`Issuance-date cutoff`	Chrome version 66 would stop trusting Symantec certificates issued before June 1, 2016. Chrome version 70 would completely remove trust for all remaining certificates from the old infrastructure, except for the small number issued by the independently operated and audited subordinate CAs.	Chrome's Plan to Distrust Symantec Certificates (Google Online Security Blog)
2018-03-12	`Announced`	Mozilla	Symantec	`Issuance-date cutoff`	Firefox version 60 would stop trusting certificates issued before June 1, 2016. Firefox version 63 would remove trust regardless of the certificate's issue date, with the exception of certificates issued by Apple and Google subordinate CAs. ⚠ The sources disagree: The Mozilla wiki states that distrust for certificates, regardless of issue date, begins in Firefox version 64.	Distrust of Symantec TLS Certificates (Mozilla Security Blog) / CA/Additional Trust Changes (Mozilla Wiki)
2018-08-01	`Effective`	Apple	Symantec	`Issuance-date cutoff`	As of August 1, 2018, Apple partially distrusted Symantec CAs. TLS certificates issued between June 1, 2016, and December 1, 2017, were trusted until the full distrust on February 25, 2020.	Information about distrusting Symantec certificate authorities (Apple Support)
2018-10-17	`Effective`	Chrome	Symantec	`TLS trust off`	In a 2018-10-17 update to the 2018-03-07 announcement, the program wrote that Chrome version 70 had been released to the Stable channel. The announcement says that, starting with Chrome version 70, the remaining Symantec certificates stop working.	Distrust of the Symantec PKI: Immediate action needed by site operators (Google Online Security Blog)
2019-03-05	`Effective`	Microsoft	WoSign / StartCom	`TLS trust off`	The monthly notice included StartCom and WoSign roots in the list of roots to be disabled in the 2019-03-05 release. The reason and who requested it were not stated. The notice describes `Disable` as removing certain capabilities of the root certificate without complete removal.	February 2019 Deployment Notice (Microsoft Trusted Root Program)
NSS 3.45 / Firefox 69	`Release Tag`	Mozilla	Certinomis	`Root removal`	The bug report stated that discussions and a list of issues on dev-security-policy led to a recommendation for removal, which was approved for NSS version 3.45 and Firefox version 69.	Bug 1552374 (Bugzilla) / Removed CA Certificate Report (CCADB)

2020–2023 — Distrust-After, NotBefore, and Root Store Removals

During this period (2020–2023), Mozilla began to hold a cutoff by issuance date as an attribute in the NSS root list. Microsoft's monthly notices also include the NotBefore category.

Date	Date Type	Root Program	CA	Mechanism	What the Program Wrote	Where It Is Written
NSS 3.53 / Firefox 78	`Release Tag`	Mozilla	Symantec	`Issuance-date cutoff`	The program stated that the list of trusted root authorities in NSS included a "Distrust-After" mechanism, which became effective with Firefox version 78. It indicated that Symantec's root had the `CKA_NSS_SERVER_DISTRUST_AFTER` property set.	CA/Additional Trust Changes (Mozilla Wiki)
2020-02-25	`Effective`	Apple	Symantec	`TLS trust off`	The page gives February 25, 2020, as the date of full distrust of Symantec's certificate authorities.	Information about distrusting Symantec certificate authorities (Apple Support)
2020-02-25	`Effective`	Microsoft	CNNIC	`Issuance-date cutoff`	The monthly notice included CNNIC's two roots in the list of roots to be designated as "NotBefore" in the February 25, 2020 release. A note in the notice says that the NotBefore and Disable dates are set for the first day of the release month, and the next sentence refers to certificates issued after January 1. The reason was not specified.	February 2020 Deployment Notice (Microsoft Trusted Root Program)
NSS 3.60 / Firefox 85	`Release Tag`	Mozilla	Symantec	`Root removal`	The program stated that ten root authorities, including GeoTrust, thawte, and VeriSign, were removed in NSS version 3.60 and Firefox version 85.	CA/Additional Trust Changes (Mozilla Wiki)
2021-01-25	`Announced`	Chrome	Camerfirma	`Blocklist`	In a Chrome Root Program post, it was stated that Chrome version 90 would no longer accept certificates issued by AC Camerfirma SA, and that this would be implemented with an integrated blocklist.	Summary of Camerfirma's Compliance Issues (dev-security-policy) / Chromium blocklist README
2021-02-04	`Announced`	Mozilla	Camerfirma	`TLS trust off`	The program stated that the websites trust bit for two roots from 2008 would be turned off in the planned changes for Firefox version 88. It noted that the S/MIME trust bit would remain. The CCADB removal list notes that turning the bit off was delayed to Firefox version 89. The post date is as displayed in the Internet Archive copy.	Camerfirma decision thread (dev-security-policy) / Removed CA Certificate Report (CCADB)
2022-02-22	`Effective`	Microsoft	Certinomis	`Issuance-date cutoff`	The monthly notice included `Certinomis - Root CA` in the list of roots to be designated as "NotBefore" in the February 22, 2022 release. The reason and the "NotBefore" date were not specified.	February 2022 Deployment Notice (Microsoft Trusted Root Program)
2022-08-23	`Effective`	Microsoft	CNNIC	`TLS trust off`	The monthly notice included CNNIC's two roots in the list of roots to be disabled in the August 23, 2022 release. The reason was not specified.	August 2022 Deployment Notice (Microsoft Trusted Root Program)
2022-11-29	`Effective`	Microsoft	TrustCor	`Issuance-date cutoff`	The monthly notice included TrustCor's three roots in the list to be designated as "NotBefore" in the November 29, 2022 release. The "NotBefore" date was not specified.	November 2022 Deployment Notice (Microsoft Trusted Root Program)
2022-11-30	`Announced`	Mozilla	TrustCor	`Issuance-date cutoff`	The program stated that the "distrust-after" dates for TLS and S/MIME for TrustCor's three roots would be set to November 30, 2022, and that roots would be removed after existing certificates expired. The post date is as displayed in the Internet Archive copy and may be December 1, 2022, in UTC.	concerns about Trustcor (dev-security-policy)
2022-12-01	`Cutoff`	Apple	TrustCor	`Issuance-date cutoff`	The program stated that all new certificates issued by TrustCor's CAs on or after December 1, 2022, were no longer trusted. Certificates issued before that date would continue to be trusted until their expiration date.	Information about distrusting TrustCor Systems Certification Authorities (Apple Support)
2022-12-15	`Announced`	Chrome	TrustCor	`Blocklist`	The program stated that Chrome, starting with version 111, would no longer trust certificates from TrustCor. The implementation involved both an integrated blocklist and removal from the Chrome Root Store. This date is the date, given in the 2023-01-13 announcement, on which Chrome communicated its decision in the public forum.	Sustaining Digital Certificate Security - TrustCor Certificate Distrust (Google Online Security Blog)
2023-02-28	`Effective`	Microsoft	TrustCor	`TLS trust off`	The monthly notice stated that TrustCor's three roots would have "Disallow Server Authentication" set in the February 28, 2023 release.	February 2023 Deployment Notice (Microsoft Trusted Root Program)
NSS 3.94 / Firefox 121	`Release Tag`	Mozilla	TrustCor	`Root removal`	The CCADB removal list stated that NSS version 3.94 and Firefox version 121 removed TrustCor's three roots.	Removed CA Certificate Report (CCADB)
2023-06-02	`Announced`	Chrome	e-Tugra	`Root removal`	In a Chrome Root Program post, it was stated that e-Tugra's two roots would be removed from the Chrome Root Store. It was expected that this change would reach many users in Chrome Root Store version 11, whose publication was expected no later than June 15, 2023. The post date comes from the capture time of the Internet Archive copy and the post's age shown in that copy.	e-Tugra thread (dev-security-policy)
NSS 3.92 / Firefox 117	`Release Tag`	Mozilla	e-Tugra	`Root removal`	The CCADB removal list stated that NSS version 3.92 and Firefox version 117 removed e-Tugra's two roots.	Removed CA Certificate Report (CCADB) / Bug 1842928 (Bugzilla)

2024–2025 — SCT-Based Cutoffs

During the 2024–2025 period, all of Chrome's rows are cutoffs by SCT date. Apple used the same date across three Certificate Authorities.

Date	Date Type	Root Program	CA	Mechanism	What the Program Wrote	Where It Is Written
2024-02-27	`Effective`	Microsoft	Camerfirma	`Issuance-date cutoff`	The program stated that in the 2024-02-27 release, it would set the NotBefore date for Server Authentication EKU on Camerfirma's root.	February 2024 Deployment Notice (Microsoft Trusted Root Program)
2024-06-27	`Announced`	Chrome	Entrust	`SCT-date cutoff`	The program stated that certificates with the earliest SCT date later than the cutoff date would not be trusted by default. According to the Internet Archive copy of 2024-06-30, the cutoff date was 2024-10-31, and the change applied to Chrome version 127 and later.	Sustaining Digital Certificate Security - Entrust Certificate Distrust (Google Online Security Blog)
2024-07-31	`Announced`	Mozilla	Entrust	`Issuance-date cutoff`	The program stated that it would set a distrust-after date for TLS certificates issued after November 30, 2024. The post date is as displayed in the Internet Archive copy and may be August 1, 2024, in UTC.	Mozilla's Decision on Entrust's Root CA Certificates used for TLS (dev-security-policy)
2024-09-10	`Announced`	Chrome	Entrust	`SCT-date cutoff`	The announcement was revised to state that the cutoff date was November 11, 2024, at 11:59:59 PM UTC, and the change applied to Chrome version 131 and later. The program indicated that blocking would begin around November 12, 2024.	Sustaining Digital Certificate Security - Entrust Certificate Distrust (Google Online Security Blog)
2024-11-15	`Cutoff`	Apple	Entrust	`Issuance-date cutoff`	The program stated that the effective date for Entrust and AffirmTrust roots was November 15, 2024.	Changes to Certification Authorities and certificates (Apple Support)
2024-11-15	`Cutoff`	Apple	Camerfirma	`Issuance-date cutoff`	The program stated that the effective date for two of Camerfirma's roots from 2008 was November 15, 2024.	Changes to Certification Authorities and certificates (Apple Support)
2024-11-15	`Cutoff`	Apple	NetLock	`Issuance-date cutoff`	The program stated that the effective date for NetLock's root was November 15, 2024.	Changes to Certification Authorities and certificates (Apple Support)
2025-02-25	`Effective`	Microsoft	Entrust	`Issuance-date cutoff`	The program stated that an update was released on February 25, 2025, and that the NotBefore date was set to April 16, 2025. The reason for the change was not specified.	February 2025 Deployment Notice (Microsoft Trusted Root Program)
2025-05-30	`Announced`	Chrome	Chunghwa Telecom / Netlock	`SCT-date cutoff`	The program stated that certificates with the earliest SCT date later than July 31, 2025, at 11:59:59 PM UTC would not be trusted by default in Chrome version 139 and later. This date is the date, given in the announcement, on which Chrome communicated its decision in the public forum.	Sustaining Digital Certificate Security - Upcoming Changes to the Chrome Root Store (Google)
2025-08-27	`Effective`	Microsoft	e-Tugra	`Issuance-date cutoff`	The program stated that in the 2025-08-27 release, the NotBefore date was set to September 15, 2025, and the notice lists the two e-Tugra roots. The reason for the change was not specified.	August 2025 Deployment Notice (Microsoft Trusted Root Program)

2026 — eMudhra

On October 17, 2026, a compromise of the private keys for eight of eMudhra's intermediate Certificate Authorities (CAs) was reported. The four root programs first blocked the intermediate CAs, then removed from their root stores, or blocked, the root that had signed those intermediate CAs. The actions that each root program took on each date are detailed in the table in the "The Same Event, Several Dates" section. How each client and AWS service responded is covered in this series' "When Intermediate CA Keys Are Compromised."

Date	Date Type	Root Program	CA	Mechanism	What the Program Wrote	Where It Is Written
2026-10-17	`Incident Reported`	Chrome	eMudhra	`Blocklist`	Wrote that it received the report at 18:05 UTC on 2026-10-17 and blocked the SPKI hashes of the intermediate CAs through an update to CRLSet at 19:45 UTC. It also wrote that `emSign ECC Root CA - G3` was removed from the Chrome Root Store on 2026-10-20, with an expected distribution on the morning of 2026-10-27 (PDT).	Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates (Google) / Chrome Root Store (Chromium source)
2026-10-17	`Effective`	Mozilla	eMudhra	`Blocklist`	Wrote that it completed the distribution of OneCRL to all standard configurations of Firefox by 2026-10-17 at 22:59 UTC. On 2026-10-20, it wrote about an update that removes the root from the NSS root list. ⚠ The sources disagree: the NSS version is written in three different ways.	Protecting Firefox users following the compromise of eMudhra intermediate certificates (Mozilla Security Blog) / Bug 2084101 (Bugzilla)
2026-10-19	`Effective`	Apple	eMudhra	`Blocklist`	Wrote that it began blocking 12 intermediate CA certificates on 2026-10-19, and also began blocking `emSign ECC Root CA - G3` on 2026-10-23.	About the compromised eMudhra intermediate CAs (Apple Support)
2026-10-20	`Effective`	Microsoft	eMudhra	`Blocklist`	Wrote that it updated the Windows Disallowed Certificate Trust List on 2026-10-20. It also wrote about removing seven certificates from the Windows trust list on 2026-10-26, and from the Microsoft Edge trust list on 2026-10-27.	Microsoft's response to compromised eMudhra certificate authority keys (MSRC) / Announcements (Microsoft Trusted Root Program)

eMudhra announced on October 22, 2026, that its board of directors has decided to withdraw from the global SSL/TLS certificate business. Because this is the CA's own decision, it is not a row in the timeline.

Events and Programs With No Statement Found

The following combinations in the table did not yield any matching statements from the search conducted in this article. This does not mean that those root programs took no action.

CA	Root Program	What Was Searched (2026-10-29)	No Statement Found
TURKTRUST	Apple	The OS X Mavericks page listing trusted root certificates and Apple's security updates page	The listing puts TURKTRUST certificates in its blocked certificates section and gives the trust setting as `Trust: Never`. No statement regarding the date or reason was found.
ANSSI	Apple	Apple's security updates page and page listing trusted root certificates	No statement regarding the action was found.
CNNIC	Apple	Page (PDF) detailing Apple's partial trust allow list	The page describes how CNNIC's root certificates are treated within a system that only trusts certificates listed on the allow list. No statement regarding the date of the action was found.
Certinomis	Chrome / Apple	Chromium's blocklist README, Apple's page 121668, and page listing trusted root certificates	No statement regarding the action was found.
e-Tugra	Apple	Apple's page 121668 and page listing trusted root certificates	No statement regarding the action was found.
Chunghwa Telecom / Netlock (2025)	Mozilla / Apple / Microsoft	The CCADB inclusion list (NetLock's root remains included, with no "distrust-after" date), Apple's page 121668 (NetLock has only the row for November 15, 2024), and five monthly notices from Microsoft in 2025, as well as GitHub's `Announcements.md`.	No statement regarding the action in 2025 was found.
All CAs	Microsoft (monthly notices)	Announcements listed in the timeline	The announcements list categories (Disable, NotBefore, Remove, Disallow Server Authentication) and fingerprints. No statement regarding the reason or who requested the action was found.
eMudhra / `emSign Root CA - G1`	Chrome / Mozilla / Microsoft	Google's announcement, Bugzilla 2083449, MSRC blog, and Chrome Root Store definition file	As of the verification date, none of the root programs has written a decision to remove G1. Chrome states that it will continue to evaluate, Mozilla writes, with the qualifier `At this time`, that it is not removing trust in G1, and Microsoft states that it will evaluate the remaining root certificates separately. Version 43 of the Chrome Root Store still includes G1.

Current Overview of How Root Programs Remove Trust

This chapter revisits each row in the timeline, examining how each root program removes trust. It details how each program defines its mechanisms, how it treats certificates issued before the cutoff, and which dates it used to record the same events.

The following figure organizes the timeline rows by root program and time period. It depicts only those rows for which a statement was found; combinations where no statement was found are listed in the table Events and Programs With No Statement Found. The absence of an entry in the figure does not mean that the root program took no action.

Web PKI CA Distrust Actions by Root Program

What the Programs Gave as Grounds

In the timeline, the row in which an operator gave a private key compromise as the reason is the 2026 eMudhra row. Google's announcement stated that the intermediate CAs' private keys were generated without sufficient randomness. In earlier rows, the operators cited a series of issues, including improper or incorrect issuance, failure to comply with rules, and unfulfilled promises of improvement, as well as behavior that undermined trust. This article quotes the operators' text without rephrasing. Microsoft's monthly notices did not specify reasons.

Chrome, in its announcement dated 2016-10-31, stated the following regarding WoSign and StartCom:

For both CAs, we have concluded there is a pattern of issues and incidents that indicate an approach to security
that is not in concordance with the responsibilities of a publicly trusted CA.

Chrome, in its announcement dated 2017-09-11, stated the following regarding Symantec:

This incident, while distinct from a previous incident in 2015, was part of a continuing pattern of issues over
the past several years that has caused the Chrome team to lose confidence in the trustworthiness of Symantec's
infrastructure, and as a result, the certificates that have been or will be issued from it.

The Chromium blocklist's README stated the following regarding Camerfirma:

As a result of a long-standing pattern of misissuances and incomplete or insufficient remediations, trust in TLS
server certificates from Camerfirma was fully removed.

Mozilla, in its post dated 2021-02-04, stated the following regarding Camerfirma:

As many of you have pointed out, there do not appear to be remediation actions that Camerfirma can take at this
time to sufficiently reduce the risk of continuing to keep the Websites trust bit enabled for the Camerfirma
root certificates.

The bug report for Mozilla's removal of Certinomis stated the following reason:

Reason: An issues list [1] and resulting discussion [2] on the mozilla.dev.security.policy list led to this
recommendation.

Mozilla, in its post regarding TrustCor's decision, stated:

Our assessment is that the concerns about TrustCor have been substantiated and the risks of TrustCor's continued
membership in Mozilla's Root Program outweighs the benefits to end users.

Chrome, in its announcement dated 2023-01-13, stated the following regarding TrustCor:

Behavior that attempts to degrade or subvert security and privacy on the web is incompatible with organizations
whose CA certificates are included in the Chrome Root Store.

Chrome, in its post dated 2023-06-02, stated that after considering information about publicly disclosed vulnerabilities and incident reports, it decided to remove the e-Tugra root certificates.

Chrome, in its announcement dated 2024-06-27, stated the following regarding Entrust:

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.

Mozilla, in its post regarding Entrust's decision, stated:

After careful consideration of the nature of these incidents, Entrust's proposal for addressing the incidents,
and the community's feedback, we have decided to set TLS distrust-after dates for the Entrust root certificates
which are currently included in Mozilla's Root Store.

Chrome, in its announcement dated 2025-05-30, stated the following regarding Chunghwa Telecom and Netlock:

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.

Apple's page 121668 does not list reasons for each CA, but instead gives, as a general reason for removal, issues related to a CA's compliance and engagement with the requirements of the Apple Root Program and industry standards (see the quote in the section Each Program's Own Terms for Each Mechanism).

Each Program's Own Terms for Each Mechanism

The following table lists, for each mechanism, the terms used in each root program, along with the documents that define or describe those terms. The sentences from those documents follow the table.

Mechanism	Root Program	Program's Own Term	Certificates Issued Before the Cutoff	Where It Is Written	No Statement Found
`Root removal`	Chrome	removal from the Chrome Root Store	—	Chrome Root Program Policy, Version 1.8	—
`Root removal`	Mozilla	disable or remove a certificate	—	Mozilla Root Store Policy, Version 3.1, Section 7.3	—
`Root removal`	Apple	removing the CA and/or specific certificates	—	Apple Support 121668	—
`Root removal`	Microsoft	removal, `Remove`	—	Microsoft Trusted Root Program `Announcements.md` (2026-10-26)	A statement defining the category `Remove`.
`TLS trust off`	Chrome	fully remove trust	—	Google announcement from 2017-09-11 (Symantec)	—
`TLS trust off`	Mozilla	Websites trust bit	—	Mozilla Root Store Policy, Version 3.1, Sections 7.3 and 7.4	—
`TLS trust off`	Apple	full distrust	—	Apple Support 103187 (Symantec)	—
`TLS trust off`	Microsoft	`Disallow Server Authentication`, `Disable`	—	Microsoft Trusted Root Program monthly notices (February 2019 for `Disable`)	A statement defining `Disallow Server Authentication`.
`Issuance-date cutoff`	Mozilla	distrust-after, `CKA_NSS_SERVER_DISTRUST_AFTER`	Trust continues until the expiration date or revocation date.	CA/Additional Trust Changes (Mozilla Wiki)	—
`Issuance-date cutoff`	Apple	effective date	Expected to function until the natural expiration of the certificate.	Apple Support 121668	—
`Issuance-date cutoff`	Microsoft	NotBefore, including NotBefore on the Server Authentication EKU	Only certificates issued after the cutoff date are not trusted.	Microsoft Trusted Root Program announcement from February 2025	A defining sentence in the policy document (program-requirements).
`SCT-date cutoff`	Chrome	SCTNotAfter	Trusted until expiry.	Chrome Root Program Policy, Version 1.8	—
`Blocklist`	Chrome	CRLSet, integrated blocklist	—	Google announcement from 2026-10-20, Chromium blocklist README	—
`Blocklist`	Mozilla	OneCRL	—	CA/Additional Trust Changes (Mozilla Wiki)	—
`Blocklist`	Apple	certificate configuration data	—	Apple Support 149555	—
`Blocklist`	Microsoft	Disallowed Certificate Trust List	—	MSRC blog (2026-10-26)	—
`Name constraint`	Chrome	metadata-based name constraints	—	Chrome Root Program Policy, Version 1.8	—
`Name constraint`	Mozilla	name-constrained	—	CA/Additional Trust Changes (Mozilla Wiki)	—
`Allowlist`	Chrome	publicly disclosed whitelist	—	Google announcement from 2015-03-23 (with addition from 2015-04-01)	—
`Allowlist`	Apple	partial trust allow list	—	Apple's partial trust allow list page (PDF)	—

For combinations not in the table, neither an action of that type nor a sentence defining that type was found in the materials this article read. For example, this applies to the combination of Apple and Microsoft's SCT-date cutoff and the combination of Apple and Microsoft's Name constraint. The exception is Chrome's Issuance-date cutoff: the timeline has rows for 2016 and 2017, but Chrome's announcements describe this cutoff in sentences without a name for it. Mozilla's wiki states that the Turkish Government CA (Kamu SM) is name-constrained to *.tr; this article did not make it a timeline row because the wiki gives no date for the constraint.

Chrome Root Program Policy, Version 1.8, states that the phase-out process is, by default, performed using SCTNotAfter.

Unless otherwise specified, phase-outs are accomplished using an SCTNotAfter constraint on a corresponding root
CA's certificate included in the Chrome Root Store. TLS server authentication certificates issued on or before a
practice's or PKI hierarchy's specified phase-out date and time will be trusted in Chrome until expiry, whereas
certificates issued after will not be trusted by default.

The same policy writes that it applies name constraints to roots as metadata.

applies metadata-based name constraints to certificates in the Chrome Root Store. These constraints, which may
go beyond those in the CA certificates themselves, restrict the use of corresponding TLS server authentication
certificates to specific Top-Level Domains (TLDs) and/or Second-Level Domains (SLDs).

Section 7.3 of Mozilla Root Store Policy, Version 3.1, describes Mozilla's discretion regarding removing trust as follows:

Mozilla MAY, at its sole discretion, decide to disable (partially or fully), or remove a certificate, at any
time and for any reason. This MAY happen immediately or on a planned future date.

Mozilla's wiki describes "distrust-after" as follows:

For some root certificates Mozilla has set 'Distrust for TLS After Date' or 'Distrust for S/MIME After Date'.
For certificates chaining up to those root certificates, Mozilla does not trust end-entity certificates that
have a Valid-From date later than the specified distrust-after date. Certificates with a Valid-From date earlier
than the distrust-after date will continue to be trusted until the certificate's natural expiration or until the
certificate is revoked.

The same wiki writes that OneCRL is not used for un-trusting roots.

While not technically a modification to the root store as we don't use it for un-trusting roots, Mozilla's
OneCRL system is used for communicating information about the revocation of intermediate certificates

Apple's page 121668 describes the removal from the root store and the meaning of the effective date as follows:

If a Certification Authority (CA) experiences issues related to its compliance and engagement with the
requirements of the Apple Root Program and broader industry standards, we take action to protect users by
removing the CA and/or specific certificates from Apple Root Stores. The listed effective date is the date after
which the affected certificates will no longer successfully validate on up-to-date Apple systems. Certificates
issued on or before the effective date are expected to function until the natural expiration of the certificate.

The documentation for Microsoft's policy (program-requirements) did not include a definition of "NotBefore." This article checked the meaning of NotBefore in the February 2025 announcement quoted above.

What Happens to Certificates Issued Before the Cutoff

With a date-based cutoff, trust in certificates issued before the cutoff does not end right away. The four root programs describe how they treat these certificates as follows:

Chrome — The policy states that certificates issued on or before the cutoff date will continue to be trusted until their expiration date (as cited above). The announcements for Entrust and for Chunghwa Telecom and Netlock state that certificates whose earliest Signed Certificate Timestamp (SCT) is on or before the cutoff date will not be affected by the change.
Mozilla — The wiki states that certificates with a "Valid-From" date prior to the cutoff date will continue to be trusted until their expiration or revocation date (as cited above).
Apple — Page 121668 states that certificates issued on or before the effective date are expected to continue functioning until their expiration date (as cited above). The TrustCor page also states that certificates issued before December 1, 2022, will continue to be trusted until their expiration date.
Microsoft — An announcement from February 2025 states that only certificates issued after the "NotBefore" date will not be trusted (as cited above).

Chrome also states that when a user or organization explicitly trusts a root, any restrictions imposed by SCTs are overridden. The Entrust announcement states:

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.

Root Removal After a Cutoff

After a date-based cutoff, a root program may also remove the root itself. Chrome Root Program Policy, Version 1.8, describes the removal of roots after a cutoff as follows:

The corresponding root CA's certificate included in the Chrome Root Store will be removed upon the absence of
unexpired and unrevoked TLS server authentication certificates

Mozilla's TrustCor decision post also states that, after setting a "distrust-after" date, the root is removed once existing certificates expire.

Remove those root certificates from Mozilla's root store after the existing end-entity TLS certificates have
expired.

In the timeline, the two steps are separate rows. For TrustCor, for example, Mozilla's distrust-after row (2022-11-30) and the CCADB root removal row (NSS version 3.94 and Firefox version 121) are separate.

Pushed Lists: CRLSet, OneCRL, Certificate Configuration Data, and the Disallowed CTL

Intermediate CA blocking utilizes lists distributed by the root programs to endpoints. These lists reach devices without browser or OS updates. In their 2026 announcements about eMudhra, the root programs write the following.

Google's announcement indicates that the CRLSet block used SPKI hashes.

At 19:45 UTC, Chrome completed corroborating the findings and landed a CRLSet update blocking the Subject Public
Key Info (SPKI) hashes of the affected intermediate CAs.

Mozilla's blog describes the distribution of OneCRL as follows:

By 22:59 UTC that same day, in less than 3 hours after we received the report, the updated OneCRL distribution
was complete for all Firefox users with standard configurations.

Apple's page 149555 states that certificate configuration data is automatically delivered.

Updates to certificate configuration data are sent to devices automatically and as needed, so you don't need to
install a software update to get this change.

The MSRC blog describes updates to the Disallowed Certificate Trust List as follows:

On October 20, Microsoft published an update to the Windows Disallowed Certificate Trust List to block the
affected certificate authorities.

Google and Mozilla, in the same announcements, write that they also removed the root for consumers that do not receive the distributed lists. Google specifies this is for other users of the Chrome Root Store who do not receive CRLSet updates, while Mozilla states that they are updating NSS to protect other applications that do not receive OneCRL. This series will address what clients who do not receive these lists should do, in "When Intermediate CA Keys Are Compromised."

The Same Event, Several Dates

A single event may have different dates depending on the root program. Within one root program, too, there are announcement, cutoff, and effective dates. The following two tables list the dates for Entrust and eMudhra, categorized by type.

Entrust (2024-2025)

Root Program	Date	Date Type	What the Program Wrote	Where It Is Written	No Statement Found
Chrome	2024-06-27	`Announced`	Announcement. According to the Internet Archive copy from 2024-06-30, the cutoff date was 2024-10-31, the start of the block is approximately 2024-11-01, and the affected versions are Chrome version 127 and later.	Google Online Security Blog	—
Chrome	2024-09-10	`Announced`	Update to the announcement. The cutoff date was changed to 11:59:59 PM UTC on 2024-11-11, and the affected versions are now Chrome version 131 and later.	Google Online Security Blog	—
Chrome	2024-11-11	`Cutoff`	Certificates with the earliest SCT date after this date will no longer be trusted by default.	Google Online Security Blog	—
Chrome	2024-11-12	`Effective`	Start of the block. The announcement says `approximately`.	Google Online Security Blog	Chrome's statement describing the actual start date of the block.
Mozilla	2024-07-31	`Announced`	Posting about the decision. The date, as displayed in the Internet Archive copy, may be 2024-08-01 in UTC.	dev-security-policy	—
Mozilla	2024-11-30	`Cutoff`	Distrust-after date. ⚠ The sources disagree: The CCADB inclusion list gives only `Entrust Root Certification Authority - G4` with the date `2024.11.19`, while the other three roots are listed with `2024.11.30`.	dev-security-policy / CCADB	Statement explaining the discrepancy between the two dates.
Apple	2024-11-15	`Cutoff`	Effective date, according to Apple.	Apple Support 121668	Date of the announcement.
Microsoft	2025-02-25	`Effective`	Date of the release of the update.	Microsoft Trusted Root Program	Reason.
Microsoft	2025-04-16	`Cutoff`	NotBefore date.	Microsoft Trusted Root Program	—

eMudhra (2026-10-17 to 2026-10-27)

Root Program	Date	Date Type	What the Program Wrote	Where It Is Written	No Statement Found
Chrome	2026-10-17	`Incident Reported`	Received a report at 18:05 UTC.	Google announcement	—
Chrome	2026-10-17	`Effective`	Blocked the SPKIs of the intermediate CAs using CRLSet at 19:45 UTC.	Google announcement	—
Mozilla	2026-10-17	`Effective`	Completed distribution of OneCRL by 22:59 UTC.	Mozilla Security Blog	—
Apple	2026-10-19	`Effective`	Began blocking certificates for 12 intermediate CAs.	Apple Support 149555	—
Microsoft	2026-10-20	`Effective`	Updated Windows' Disallowed Certificate Trust List. Also updated CRLSet for Edge and WebView2.	MSRC blog	—
Chrome	2026-10-20	`Announced`	Removed `emSign ECC Root CA - G3` from the Chrome Root Store.	Google announcement	—
Chrome	Chrome Root Store Version 43	`Release Tag`	In the Chromium source, a commit on 2026-10-20 updated the Chrome Root Store to version 43, removing G3. Version 43 retains `emSign Root CA - G1`.	Chrome Root Store (Chromium source)	—
Chrome	2026-10-27	`Effective`	Stated that the removal of G3 was expected to be distributed to all devices by the morning of 2026-10-27 (PDT).	Google announcement	A Chrome statement describing when the distribution was actually completed.
Mozilla	2026-10-20	`Announced`	Announced an update removing G3 from the list of roots in NSS.	Mozilla Security Blog	—
Mozilla	NSS 3.131.1 / NSS 3.132 / Firefox 160	`Release Tag`	⚠ The sources disagree: The blog states version 3.131.1 for NSS. Both the release notes for NSS version 3.131.1 (2026-10-20) and version 3.132 (2026-10-21) list bug 2084101, which addresses the removal of G3. The CCADB removal list gives NSS version 3.132 and Firefox version 160.	Mozilla Security Blog / NSS release notes / CCADB	A statement explaining the three discrepancies.
Apple	2026-10-23	`Effective`	Began blocking `emSign ECC Root CA - G3`.	Apple Support 149555	—
Microsoft	2026-10-26	`Effective`	Through an out-of-band Windows update, removed seven certificates from the Windows trust list.	MSRC blog / `Announcements.md`	—
Microsoft	2026-10-27	`Effective`	Removed the same seven certificates from the Microsoft Edge trust list.	MSRC blog	—

The MSRC blog details the seven certificates that were removed, as follows:

six eMudhra G3 roots and an AAA Certificate Services cross-sign

The root that Google and Mozilla removed is one root, emSign ECC Root CA - G3. This article does not verify the correspondence between the G3 root certificates counted by Microsoft and the root removed by Google and Mozilla.

Where the Sources Disagree

Among the data referenced in the timeline, the sources give different values for the following three matters. This article presents both values without designating either as incorrect.

The Firefox version for distrusting Symantec certificates regardless of issuance date — the Mozilla Security Blog (2018-03-12) lists Firefox version 63, while Mozilla's wiki lists Firefox version 64. The same wiki also says that Mozilla plans to remove the preference that switches the distrust in Firefox version 65.
The NSS version that removed eMudhra's emSign ECC Root CA - G3 — the Mozilla Security Blog lists NSS version 3.131.1. Both release notes for NSS versions 3.131.1 and 3.132 list the same bug. The CCADB removal list gives NSS version 3.132 and Firefox version 160. Bugzilla entry 2084101 lists the NSS version as being changed from 3.131 to 3.132.
The distrust-after date for Entrust's Entrust Root Certification Authority - G4 — Mozilla's announcement states 2024-11-30 for nine roots. The CCADB inclusion list gives only G4 as 2024.11.19.

Frequently Asked Questions about Web PKI CA Distrust

Is removing a root the same as distrusting it?

In this article's terms, removing a root is not the same as distrusting it. Removing a root involves excluding it from the root store. After removal, certificates along paths ending with that root will no longer be trusted. However, if the same intermediate CA is cross-signed by a different root, those paths will be treated separately. Apple's page 149555 states that even when emSign ECC Root CA - G3 is removed, macOS command-line tools using /etc/ssl/cert.pem can still validate six certificates cross-signed by Sectigo, via AAA Certificate Services. Distrust means removing trust in the certificates below a root while keeping the root, and it includes date-based cutoffs. With a date-based cutoff, certificates issued before the cutoff stay trusted. The Chrome Root Program Policy, Version 1.8, states that, after a cutoff, the root is removed when no unexpired and unrevoked certificates remain. The two can be used one after the other.

Do certificates issued before the cutoff stop working?

Regarding date-based cutoffs, certificates issued before the cutoff date will not immediately cease to function. Chrome's policy states that it trusts certificates until their expiration date, and Mozilla's wiki states that trust continues until the expiration date or until the certificate is revoked. Apple's page 121668 states that certificates issued on or before the effective date are expected to continue functioning until their expiration. Microsoft's notice states that it only distrusts certificates issued after the NotBefore date. However, root removal and blocking have no such treatment. Among the date-based cutoffs, the Symantec distrust in stages was the exception: Chrome version 66 and Firefox version 60 stopped trusting certificates issued before June 1, 2016. Apple's 2018-08-01 stage also did not trust certificates issued before its cutoff date.

Is "revoked" the same as "distrusted"?

They are not the same. "Revoke" refers to a Certificate Authority invalidating a certificate it issued. "Distrust," "remove," and "block" are actions performed by root programs. Microsoft's Trusted Root Program, in an announcement dated October 26, 2026, states that revocation and removal are separate actions. However, documents from Mozilla and Microsoft, starting in 2011, use the term "revoke" to describe actions performed by root programs. This article quotes the operators in their own words.

Did Apple and Microsoft act on the same dates as Chrome and Mozilla?

Apple and Microsoft did not take action on the same dates as Chrome and Mozilla. For Entrust, the cutoff dates were 2024-11-11 for Chrome, 2024-11-30 for Mozilla (the CCADB gives 2024-11-19 for the G4 root), 2024-11-15 for Apple, and 2025-04-16 for Microsoft. For eMudhra, Chrome and Mozilla began blocking the intermediate CAs on 2026-10-17, Apple on 2026-10-19, and Microsoft on 2026-10-20. For some CAs, no statement from Apple or Microsoft was found in the range this article searched. These instances are listed in the table Events and Programs With No Statement Found.

What are CRLSet and OneCRL?

Both CRLSet and OneCRL are lists of certificates that browser operators distribute to devices to block. Chrome uses CRLSet, and Mozilla uses OneCRL. Google's 2026 announcement states that the CRLSet update protected Chrome users without requiring a browser update or restart, and Mozilla's blog states that the OneCRL distribution was complete for all Firefox users with standard configurations. According to Mozilla's wiki, OneCRL is used to communicate information about the revocation of intermediate certificates, and is not used to remove trust for root certificates. Apple uses certificate configuration data, and Microsoft uses the Windows Disallowed Certificate Trust List.

Can an enterprise override a Chrome distrust?

Restrictions based on SCTs can be overridden. Chrome's announcements for Entrust and for Chunghwa Telecom and Netlock state that if a user or enterprise explicitly trusts a specific root on a platform and Chrome version that relies on the Chrome Root Store, the SCT restrictions are overridden. The announcement for 2025 states that from Chrome version 127 onwards, enterprises can override Chrome Root Store restrictions by adding the root as a trusted root locally on the device. Whether it is possible to override blocks imposed by CRLSet is not mentioned in the materials reviewed for this article. For the integrated blocklist used for Camerfirma, the 2021 Chrome Root Program post states that users and enterprise administrators will not be able to bypass or override the warning.

Summary

This article presents a timeline, from DigiNotar in 2011 to eMudhra in 2026, detailing instances of Certificate Authority (CA) distrust by Chrome, Mozilla, Apple, and Microsoft, categorized by the type of removal and the dates involved.

There are different types of removal. This article categorizes these removals into seven types: root removal, removal of TLS trust, cutoffs by issuance date, cutoffs by Signed Certificate Timestamp (SCT) date, blocks with distributed lists, name constraints, and trust limited to a published list.

Date-based cutoffs increased. From 2011 to 2015, rows primarily involved root removals and the blocking of intermediate CAs. After Mozilla's CNNIC cutoff in 2015, and starting in 2016 with WoSign and StartCom, there was an increase in keeping trust in certificates issued before the cutoff. In 2024 and 2025, Chrome's rows are cutoffs by SCT date.

A single event may have multiple dates. Announcement dates, cutoff dates, effective dates, and version numbers are all distinct. Entrust's cutoff date differed across the four root programs.

Read the reasons in the operators' own words. The eMudhra row cites a compromised private key as the reason. For earlier rows, the reasons typically involved a combination of improper or incorrect issuance practices and non-compliance with rules. Microsoft's monthly notices do not provide specific reasons.

"Revoke" and "distrust" are separate actions. Microsoft explicitly states that revocation and removal are distinct processes. The terminology used by operators may sometimes differ from the categorization used in this article, depending on the timing and the operator involved.

⚠ Some things are not written down. For some combinations, no statement from Apple or Microsoft was found. There are three instances where the data from different sources conflicts. All information is current as of October 29, 2026.

This timeline will be updated as root program policies and CA distrust decisions continue to evolve.

In addition, there are related history-and-timeline articles on this site, so please have a look if you are interested.

References:

References:
Tech Blog with curated related content

Written by Hidekazu Konishi