Firefox’s Mozilla Follows Google in Distrusting Entrust’s TLS Certificates

Quick answer: Mozilla stopped trusting Entrust’s TLS root certificates issued after November 30, 2024, a month after Google Chrome’s November 11, 2024 cutoff, over years of unresolved compliance failures. Entrust later sold its entire public certificate business to Sectigo, completing the move on September 18, 2025. Organizations still on Entrust certificates should migrate now and automate lifecycle management.

Entrust spent decades as one of the internet’s established certificate authorities, trusted by roughly 10% of the Fortune 500 to secure their primary web properties. That changed in 2024. Google Chrome and Mozilla Firefox both removed Entrust from their root trust stores after years of unresolved compliance failures, and the fallout did not stop there: Entrust went on to sell its entire public certificate business to Sectigo in 2025. For any organization that still has Entrust issued certificates in its environment, or that wants to understand how a certificate authority loses browser trust, here is the complete, current picture.

Executive Summary

Entrust lost browser trust in stages: Google Chrome cut off new Entrust certificates on November 11, 2024, Apple followed on November 15, 2024, and Mozilla Firefox followed on November 30, 2024, all citing years of unresolved compliance failures rather than one incident. Entrust then sold its entire public certificate business to Sectigo, completing the transition on September 18, 2025. The same underlying pressure, an industry moving away from tolerating slow, manual certificate governance, is what is also driving the CA/Browser Forum’s Ballot SC-081v3, which phases maximum public TLS certificate validity down to 200 days in March 2026, 100 days in March 2027, and 47-day TLS certificates by March 2029. DigiCert’s July 2025 Trust Pulse Survey found 45% of enterprises had certificate-related downtime in the past year, with 37.5% traced to an expired certificate (Source: DigiCert Trust Pulse Survey, July 2025). Organizations that could not quickly answer “which of our certificates come from Entrust” in late 2024 are the same organizations that will struggle with 47-day renewal cycles in 2029; both problems trace back to the same gap in certificate discovery and automation.

Jump to: Key Takeaways | Timeline | Impact by Role | Readiness Checklist | Migration Roadmap | How EC Can Help | FAQ

Key Takeaways

• Mozilla Firefox stopped trusting Entrust TLS certificates issued after November 30, 2024, one month after Google Chrome’s November 11, 2024 cutoff and Apple Safari’s November 15, 2024 cutoff.
• Both browsers cited years of unresolved compliance failures, not a single incident, as the reason for distrust.
• Entrust went on to sell its entire public certificate business to Sectigo, announced January 29, 2025 and completed September 18, 2025.
• Akamai advised customers to replace Entrust origin certificates and removed Entrust and AffirmTrust roots from its trust store by March 1, 2025.
• The CA/B Forum’s Ballot SC-081v3, passed April 2025, cuts maximum public TLS certificate validity to 200 days by March 15, 2026, 100 days by March 15, 2027, and 47 days by March 15, 2029, making manual CA transitions increasingly unmanageable.
• DigiCert’s July 2025 Trust Pulse Survey found that 45% of enterprises experienced certificate related downtime in the past year, and 37.5% of those outages traced back to expired certificates.

Google’s Initial Decision to Distrust Entrust

In June 2024, Google’s Chrome Root Program was the first to announce it would stop trusting Entrust as a certificate authority (CA), citing a pattern of concerning behaviors observed over several years. Numerous compliance incidents had eroded Google’s confidence in Entrust’s ability to meet the Chrome Root Program’s requirements. Chrome’s blocking action applies to Entrust certificates with an earliest Signed Certificate Timestamp (SCT) dated after November 11, 2024, 11:59:59 PM UTC, enforced starting with Chrome 131.

Mozilla’s Decision to Distrust Entrust

Mozilla’s root store manager, Ben Wilson, explained the decision in a public post to the Mozilla dev-security-policy forum, noting that Entrust’s response did not inspire confidence despite the company’s stated efforts to address the issues. Wilson emphasized that Entrust’s updated report did not differ meaningfully from commitments the company made in 2020, commitments that were subsequently broken.

Mozilla’s decision rested on three factors:

• Repeated compliance failures: Between March and May 2024, Mozilla logged 22 separate incidents involving Entrust, many tied to delays and missed deadlines.
• Inadequate response: Entrust’s response to Mozilla’s concerns did not demonstrate a meaningful change in its operations.
• Historical context: Entrust’s previous commitments from 2020 were not upheld, which shaped Mozilla’s confidence in the 2024 response.

Entrust Distrust Timeline: Effective Dates, Impact, and Sources

The table below lays out every confirmed milestone in the Entrust distrust, from the initial browser cutoffs through Entrust’s exit from the public certificate business and the industry wide shift to shorter certificate lifespans.

Effective Date	Requirement	Who Is Impacted	Action Needed	Source
November 11, 2024	Google Chrome stops trusting new Entrust TLS certificates (SCT dated after this cutoff)	Chrome 131+ users on Windows, macOS, ChromeOS, Android, and Linux	Replace any Entrust certificate issued after this date	Google Online Security Blog
November 15, 2024	Apple distrusts new certificates from affected Entrust roots	Safari and other Apple platform users	Confirm no new Entrust issued certificates rely on Apple trust after this date	DigiCert Entrust Certificate Distrust guidance
November 30, 2024	Mozilla Firefox stops trusting new Entrust TLS certificates	Firefox users on all platforms, plus non-browser software that relies on the Mozilla trust store	Replace any Entrust certificate issued after this date	Mozilla dev-security-policy announcement
March 1, 2025	Akamai removes Entrust and AffirmTrust roots from its origin trust store	Akamai customers using Entrust certificates at origin	Replace origin certificates before this date	Akamai customer guidance
March 11, 2025	Entrust stops issuing new public TLS certificates from its own root CAs	All Entrust TLS certificate customers	Begin migrating certificate issuance to Sectigo	Entrust TLS Certificate Information Center
September 18, 2025	Entrust completes the transition of its public certificate business to Sectigo	All remaining Entrust public certificate customers	Complete migration to Sectigo for any renewals	Entrust TLS Certificate Information Center
March 15, 2026	CA/B Forum cuts maximum public TLS certificate validity to 200 days	All organizations operating public facing TLS certificates	Move to a 6-month renewal cadence and evaluate automation	CA/B Forum Ballot SC-081v3 (via Sectigo)
March 15, 2027	Maximum public TLS certificate validity drops to 100 days	All organizations operating public facing TLS certificates	Move to a 3-month renewal cadence	CA/B Forum Ballot SC-081v3 (via Sectigo)
March 15, 2029	Maximum public TLS certificate validity drops to 47 days	All organizations operating public facing TLS certificates	Fully automate certificate issuance and renewal	CA/B Forum Ballot SC-081v3 (via Sectigo)

Implementation note: this table reflects the URL of this post as staged. If the published URL differs from what is shown here, update this row before publishing to production.

Akamai’s Response for Enterprise Customers

Following Google’s decision, Akamai issued specific guidance for customers running Entrust issued certificates. Akamai continued supporting Entrust issued edge certificates on its Secure CDN until they expired, but recommended replacing them proactively to avoid disruption for Chrome clients. For origin connections, Akamai removed Entrust and AffirmTrust root certificates from its trust store by March 1, 2025. Customers who had not replaced affected certificates by that date risked interrupted secure traffic to their origin infrastructure.

Why Browsers Distrust Certificate Authorities

The Role of CAs and Compliance

CAs establish trust on the internet by issuing certificates that enable encrypted connections between browsers and websites. To maintain that trust, CAs must follow strict industry standards defined by the CA/Browser (CA/B) Forum’s Baseline Requirements. These standards cover:

• Validation processes: Proper validation of certificate requests to confirm the authenticity of the requesting entity.
• Operational security: Robust security measures that protect the CA’s infrastructure and prevent unauthorized certificate issuance.
• Adherence to protocols: Compliance with established protocols for certificate issuance, management, and revocation.

Audits and Accountability

CAs are held accountable through regular audits conducted by independent third parties. These audits verify compliance with the CA/B Forum’s Baseline Requirements. Failing to meet these standards can lead browsers to distrust a CA’s certificates entirely.

The CA Distrust Decision Making Process

When a browser like Google Chrome or Mozilla Firefox decides to distrust a CA, the process typically follows four stages:

• Evidence gathering: Investigating the CA’s issuance processes, operational security, and adherence to industry standards, drawn from transparency logs, forums, and public disclosures.
• Assessment against standards: Evaluating the evidence against the CA/B Forum’s Baseline Requirements to determine compliance.
• Public disclosure and response: Sharing findings with the CA and the public, giving the CA a chance to respond and outline corrective actions.
• Final decision: Based on the CA’s response and the severity of the issues, the browser may proceed with distrust if the response is deemed insufficient.

The Impact of Distrust on Enterprises

When a CA is distrusted, every certificate it issued stops being recognized as valid by the affected browser. The practical consequences are significant:

• Security warnings: Websites using certificates from the distrusted CA display browser warnings, which can erode user trust and expose real vulnerabilities.
• Compliance risks: Organizations that fail to replace distrusted certificates may face regulatory violations and audit findings.
• Operational disruptions: Replacing certificates at scale can interrupt service, raise operational costs, and consume significant staff time.

The Detailed Mechanism of CA Distrust

1. Incident reporting: The process starts with detection and reporting of compliance incidents, often surfaced by security researchers, other CAs, or automated monitoring systems.
2. Initial review: The CA/B Forum or the browser’s root store team conducts an initial review. Serious incidents trigger a more thorough investigation.
3. Investigation: The investigation examines the CA’s issuance practices, audit reports, and overall security posture.
4. Public disclosure: Findings are made public, and the CA is given the opportunity to respond and outline corrective actions.
5. Evaluation of response: The browser’s root store team evaluates whether the CA’s response and corrective actions are adequate.
6. Distrust decision: If the response falls short, the browser proceeds with distrust and updates its root store to remove trust in the CA’s root certificates.
7. Impact on certificates: Every certificate issued by the distrusted CA becomes invalid in that browser, and affected organizations must replace them with certificates from a trusted CA.

Historical Precedent: The Symantec Distrust

The Entrust distrust echoes the 2018 case involving Symantec. Google found multiple instances of improper certificate issuance by Symantec, which led to a phased removal of trust in Symantec certificates across major browsers. That process ultimately ended with Symantec selling its CA business to DigiCert, the same outcome pattern Entrust followed six years later with its sale to Sectigo.

The Bigger Picture: Shrinking Certificate Lifespans Raise the Stakes

The Entrust distrust is not an isolated event. It is one data point in a broader move toward shorter certificate lifetimes and less tolerance for manual certificate management. A DigiCert Trust Pulse Survey published July 2, 2025 found that 45% of enterprises experienced certificate related service downtime in the past year, and 37.5% of those outages were traced specifically to expired certificates. Manual certificate tracking is already failing organizations under today’s 398-day maximum validity period.

That challenge is about to intensify. On April 11, 2025, the CA/B Forum passed Ballot SC-081v3, a Sectigo endorsed measure that phases the maximum public TLS certificate validity down from 398 days to 200 days on March 15, 2026, to 100 days on March 15, 2027, and finally to 47 days on March 15, 2029. Every renewal cycle that used to happen once a year will need to happen roughly every six weeks by 2029. A CA distrust event under that schedule would leave enterprises almost no room to react manually, which is exactly why certificate automation has moved from a convenience to a requirement.

Enterprise Impact by Role and Deadline

Responding to a CA distrust event, and preparing for shorter certificate lifespans, spans more than one team. This matrix maps what changes for each group and what to do about it.

Team	What This Means for You	Immediate Action	Deadline to Track
PKI / Certificate Team	Directly owns any remaining Entrust issued certificates and the shrinking validity runway	Inventory every Entrust certificate still in production and confirm the replacement CA	Immediate, then March 15, 2026 for 200-day validity
Security Team	Owns the risk assessment for CA trust changes and the incident response plan for future distrust events	Add CA distrust and certificate expiry scenarios to the incident response plan	Ongoing
Platform / Infrastructure Team	Operates the servers, load balancers, and CDNs where certificates are deployed	Confirm automation protocols such as ACME, SCEP, or EST are enabled at every certificate touchpoint	Before March 15, 2026
Compliance Team	Must demonstrate certificate governance for frameworks such as PCI DSS, HIPAA, and DORA	Document the CA migration and retain evidence of certificate replacement	Aligned to each framework’s audit cycle

Certificate Lifecycle Readiness Checklist

• Inventory every certificate still issued by Entrust or any other distrusted CA.
• Confirm which internal systems pin directly to Entrust root certificates rather than validating the full chain.
• Test automated enrollment protocols, including ACME, SCEP, and EST, against your replacement CA.
• Set expiry alerts at 30, 14, and 7 days ahead of any certificate approaching end of life.
• Document the migration as compliance evidence for PCI DSS, HIPAA, or DORA audits.
• Review vendor and SaaS dependencies that may still reference Entrust roots internally.

Migration Roadmap: What to Do Next

1. Run a full certificate discovery scan across public and private CAs to find any remaining Entrust issued certificates.
2. Prioritize replacement for customer facing and revenue critical domains first.
3. Select a replacement CA (Sectigo now issues Entrust’s former public certificate volume directly) and confirm its automation protocol support.
4. Automate reissuance and renewal through ACME, SCEP, or EST instead of manual requests.
5. Extend the same automation to certificates approaching the 200-day, then 100-day, then 47 day validity milestones.
6. Re-test disaster recovery and incident response plans against a simulated CA distrust event.

Multi-Cloud and Hybrid PKI Considerations

Organizations running certificates across AWS, Azure, Google Cloud, and on-premises PKI face a harder version of this problem. Each environment tends to have its own certificate store, renewal tooling, and CA relationships. A CA distrust event or a validity period cut affects all of them at once, but rarely on the same timeline. Centralizing discovery and automation across every cloud and on-premises CA, rather than managing each environment separately, is what keeps an event like the Entrust distrust from becoming a multi-week fire drill in a hybrid environment. Building this kind of crypto agility now is also the groundwork for the post-quantum migration that follows the same shrinking-lifespan logic.

How Encryption Consulting Can Help

Encryption Consulting helps enterprises get ahead of certificate authority changes like the Entrust distrust before they become emergencies. CertSecure Manager gives PKI and security teams a single dashboard to discover every certificate across public CAs, private CAs, and cloud environments, automate renewals through ACME, SCEP, and EST, and enforce policy so no certificate depends on a single CA relationship.

For teams that need full visibility into their cryptographic footprint before a migration, CBOM Secure builds a continuously maintained Cryptographic Bill of Materials (CBOM) of every certificate, algorithm, and key across the estate, mapped to the compliance frameworks that require it. And because CA distrust events and shrinking certificate lifespans are both symptoms of the same shift toward crypto agility, our PQC Center of Excellence and PQC readiness advisory help teams build a roadmap that covers both today’s certificate authority risk and tomorrow’s post-quantum transition.

Conclusion

The distrust of Entrust by Mozilla and Google, and Entrust’s eventual exit from the public certificate business, underscores how quickly strict compliance failures can end a CA’s standing. Organizations relying on digital certificates need to stay vigilant and able to adapt fast when the CA landscape shifts. That means moving away from manual tracking and toward automated, continuously verified certificate lifecycle management, especially as the CA/B Forum’s validity schedule pushes every organization toward 47-day certificates by 2029.

Understanding how and why CA distrust happens, and building the crypto agility to respond to it without disruption, is what separates organizations that treat a distrust event as a routine maintenance task from those that treat it as an emergency.

Frequently Asked Questions

What is the main takeaway from Firefox’s Mozilla Follows Google in Distrusting Entrust’s TLS Certificates?

The core lesson is that certificate authority trust can end quickly once a CA accumulates enough compliance failures. Mozilla and Google both removed Entrust from their root stores in late 2024, and Entrust eventually sold its entire public certificate business to Sectigo in 2025. Enterprises that depended on a single CA had to migrate under time pressure, which is exactly the scenario automated certificate lifecycle management is built to prevent.

Why does this matter for enterprise certificate lifecycle management?

A CA distrust event turns every certificate from that authority into a ticking clock, regardless of its original expiration date. Enterprises managing certificates manually often discover Entrust dependent certificates late, during incident response rather than during planning. Automated lifecycle management maintains a live inventory and can trigger bulk reissuance the moment a CA’s trust status changes, avoiding the scramble manual tracking creates.

What teams are responsible for acting on this guidance?

PKI and certificate teams own the technical migration of affected certificates. Security teams own the risk assessment and incident response planning for CA trust changes. Platform and infrastructure teams operate the servers, load balancers, and CDNs where certificates are deployed and must confirm automation support. Compliance teams document the migration as evidence for frameworks such as PCI DSS, HIPAA, and DORA.

What risks increase if this topic is handled manually?

Manual certificate management raises the odds of missing an Entrust dependent certificate until it triggers a browser security warning or an outage. DigiCert’s July 2025 Trust Pulse Survey found that 45% of enterprises experienced certificate related downtime in the past year, with 37.5% of those incidents caused by expired certificates. Manual tracking also struggles to keep pace as maximum certificate validity shrinks toward 47 days.

How does automation reduce certificate outage risk?

Automation protocols such as ACME, SCEP, and EST let a certificate lifecycle management platform detect an approaching expiration or a CA trust change and reissue the certificate without a manual request. This removes the human delay behind most certificate related outages and keeps renewal cadence consistent even as validity periods drop from 398 days today to 47 days by March 2029.

What metrics should teams track after implementation?

Track the percentage of certificates under automated renewal versus manual, the number of certificates nearing expiration inside a 30-day window, mean time to reissue after a CA trust change, and the count of certificates still pinned to a single CA. Compliance teams should also track audit readiness, such as how quickly a complete certificate inventory can be produced on request.

How does this connect to 47-day TLS certificate readiness?

The Entrust distrust and the CA/B Forum’s move to 47-day certificate validity are both symptoms of the same shift: the web PKI is tightening trust requirements and shrinking the window in which a non-compliant CA relationship can cause damage. Organizations preparing for 47-day certificates and organizations recovering from a CA distrust event need the same capability: full automation of certificate discovery, issuance, and renewal.

How should this be handled in multi-cloud or hybrid PKI environments?

Multi-cloud and hybrid environments should centralize certificate discovery and automation rather than managing each cloud provider or on-premises CA separately. A CA distrust event or a validity period change affects every environment at once, but each cloud platform has its own native tooling and renewal timeline. A unified certificate lifecycle management platform spanning AWS, Azure, Google Cloud, and on-premises PKI prevents any single environment from becoming a blind spot.