CA Distrust Events: How Distrust Works and How to Switch CAs

When a browser root programme decides to stop trusting a certificate authority, every organisation using that CA has a fixed number of weeks to replace its certificates, and those without a certificate inventory or a second CA find out from user-facing error pages. Distrust is not the same as revocation or compromise: it is usually a scheduled policy decision, announced in advance, that removes default trust for certificates issued after a cut-off date while letting older ones run to expiry. This guide explains how distrust works in practice (SCT date cut-offs in Chrome, issuance date cut-offs in other root stores), what the recent official cases looked like, how to find affected certificates and the clients that depend on them, how to switch CAs quickly, and how to test. It is written for PKI owners, platform and web operations teams. Routine renewal is covered in the Machine Identity, PKI and Certificate Lifecycle Guide, and the incident procedure in the CA Compromise and Mass Certificate Replacement Playbook; this page covers the mechanics and readiness in between.

Key takeaways

• Distrust is usually date-based, not immediate. Chrome's recent actions removed default trust only for certificates whose earliest Signed Certificate Timestamp (SCT) is after a stated cut-off; existing certificates kept working.
• Each root store acts separately. Chrome, Apple and Mozilla publish their own decisions, dates and mechanisms, so one CA can be distrusted on different dates on different platforms.
• The warning period is short. Google announced the Entrust decision on 27 June 2024 with a cut-off of 11 November 2024, and the Chunghwa Telecom and NetLock decision on 30 May 2025 with a cut-off of 31 July 2025.
• Your exposure is wider than websites. Private trust stores, pinned roots, appliances and partner integrations decide what breaks, not just browsers.
• CA agility is the control. Automated issuance (ACME), a contracted second CA and a complete inventory turn a distrust announcement into a routine change.

What is changing and why

Browsers and operating systems ship root stores: lists of CA certificates trusted by default. Each store is run by a root programme with its own policy. When a CA repeatedly fails to meet those policies, the programme can remove or constrain it. Google's stated reasons for its Entrust decision were a pattern of compliance failures, unmet improvement commitments and "the absence of tangible, measurable progress in response to publicly disclosed incident reports". It gave the same reasons, together with loss of integrity, for Chunghwa Telecom and NetLock in 2025.

Three mechanisms appear in official announcements:

The SCT approach matters because a CA controls the notBefore field but not the timestamp issued by an independent Certificate Transparency log, so a CA cannot backdate certificates to escape the cut-off. See the Certificate Transparency Guide for how SCTs are produced.

Official timeline and current status

Dates below are from each programme's own announcement, checked on 8 November 2026. They are past events used as reference cases; future decisions will have their own dates.

Mozilla's handling of Entrust and other recent cases is not listed on the Mozilla page fetched for this guide, so it is not summarised here. Check each root programme's own pages for current status rather than relying on a single browser's decision.

Who and what is affected

• Public websites and APIs: users see a full-page interstitial for affected certificates in Chrome, as Google's announcement states. API clients that use the operating system or browser store fail the TLS handshake.
• Mobile apps: apps on Apple platforms follow Apple's decision; Chrome on iOS is excluded from Chrome's own constraint because Apple policies prevent use of the Chrome Certificate Verifier there.
• Machine-to-machine clients: Java, Python, Go and container images carry their own CA bundles, updated on their own schedules. Some will keep trusting a distrusted CA for months; others drop it suddenly in a library update. See Certificate trust stores and root CA management.
• Pinned roots or intermediates: apps or devices that pin to the old CA break when you switch, so the migration needs a client release first. See Certificate Pinning.
• S/MIME, code signing and timestamping: some decisions cover more than TLS. Apple's Entrust decision explicitly included S/MIME and timestamping.
• Enterprises with local overrides: from Chrome 127, installing the affected root as a locally trusted root overrides Chrome's constraint, and the 2025 announcement also names the CACertificates enterprise policy. That suits internal use only; it does nothing for external visitors.

Finding affected systems and identities

1. Start from Certificate Transparency: search CT logs for every certificate issued for your registered domains and group by issuing CA. This finds certificates bought outside central procurement. See the Certificate Transparency Monitoring Guide for Web Teams.
2. Scan your endpoints: scan external and internal TLS listeners (443 and other service ports, load balancers, CDNs, mail and VPN gateways) and record the full chain, root, earliest SCT date and expiry.
3. Check by Organization field: Google advised site operators to check the Organization (O) field in the certificate viewer; for the Entrust case, "Entrust" or "AffirmTrust" meant action was required. Apply the same check to the issuer of every certificate in the inventory.
4. Find the dependent clients: search code repositories, container images and configuration management for bundled CA files, pinned hashes and explicit trust of the affected roots. These are the clients that break when you change CA.
5. Find the owners and identities: map each certificate to an application owner and to the service account or automation identity that renews it. Certificates renewed by hand under a departed engineer's account are the slowest to move.
6. Calculate the deadline per certificate: any certificate that will need renewal after the cut-off must move to a new CA before its renewal date. Certificates that expire before the cut-off can renew once more with the old CA if policy allows, which buys time but not much.

Measure readiness with: percentage of public certificates with a known owner; percentage issued through automation; number of CAs in use and whether a second CA is contracted; median time to replace a certificate end to end; and count of clients with pinned or bundled roots.

Migration options

Small organisations with a few public sites should move straight to an automated CA. Large organisations should treat the event as a test of CA agility: contract two CAs, keep both integrated with the certificate management platform and spread issuance so that either can carry the load.

Testing and rollback

1. Simulate the distrust: from Chrome 128, Google provides a command-line flag, --test-crs-constraints with an sctnotafter value, to simulate an SCT-based distrust for given root hashes. Chrome must be fully closed before starting with the flag. Use it on test devices to see which of your sites would fail.
2. Test new chains on every client family: browsers, mobile apps, Java and other runtime trust stores, partner systems and appliances. Older devices may not trust newer roots.
3. Change in rings: non-production first, then low-traffic production, then high-traffic and partner-facing endpoints.
4. Keep rollback simple: keep the previous certificate and key available until the cut-off. Before the cut-off, rolling back to the still-trusted old certificate is safe; after it, rollback means another new certificate, not the old CA.
5. Monitor: watch TLS handshake failure rates, client error reports and synthetic checks from several platforms for two weeks after each ring.

Risks of doing nothing

• Outages at renewal: nothing breaks on announcement day; the failure arrives when the first certificate issued after the cut-off is deployed, often by automation no one is watching.
• Unsafe workarounds: teams under pressure install distrusted roots locally or disable verification in clients. Adding roots to trust stores is also an adversary technique (ATT&CK T1553.004 Install Root Certificate), so uncontrolled overrides weaken your detection of real abuse.
• Inconsistent trust: one platform trusts a certificate and another rejects it, producing intermittent faults that are slow to diagnose.
• Repeat exposure: organisations that swap CA by hand once will face the same scramble at the next event, and certificate lifetimes are shortening. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Practitioner checklist

• Subscribe to announcements from the Chrome, Apple, Mozilla and Microsoft root programmes and to your CAs' notices.
• Keep a certificate inventory reconciled weekly against CT log results for your domains.
• Record issuer, root, earliest SCT date, expiry, owner and renewing identity for every public certificate.
• Contract and integrate a second public CA before you need it.
• Automate issuance with ACME or your certificate platform wherever clients allow.
• Find and document every pinned or bundled root in code, containers and devices.
• Rehearse a CA switch on a test domain, using Chrome's constraint simulation flag.
• Control and log any local trust override and set a removal date.

Standards and references

• Google Online Security Blog: Sustaining Digital Certificate Security, Entrust Certificate Distrust
• Google: Sustaining digital certificate security, upcoming changes to the Chrome Root Store
• Apple Support: Entrust distrust in the Apple root certificate programme
• Mozilla: CA Additional Trust Changes
• Google: Chrome Root Program
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: T1553.004 Install Root Certificate

Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · CA Compromise and Mass Certificate Replacement Playbook · Certificate trust stores and root CA management · Certificate Transparency Guide · S/MIME Baseline Requirements