Browsers & root programs
Entrust distrust: Chrome, Mozilla and Apple reject new certs
From 12 November 2024 Chrome stopped trusting newly issued TLS certificates that chain to Entrust's public roots. Google announced the decision on 27 June 2024, and Mozilla and Apple set distrust dates of their own. Certificates issued before each cutoff stayed valid until they expired, so the change affected renewals rather than certificates already deployed.
What happened
Google cited a pattern of compliance failures and unmet improvement commitments at Entrust. Chrome 131 and later distrust TLS certificates that chain to 9 Entrust and AffirmTrust roots if their earliest SCT is dated after 2024-11-11 23:59:59 UTC. Using the Certificate Transparency timestamp rather than the certificate's own start date prevents a CA from backdating new certificates to slip under the cutoff.
| Platform | Distrusts certificates issued after |
|---|---|
| Chrome 131+ | 2024-11-11 23:59:59 UTC (earliest SCT) |
| Apple | 2024-11-15 |
| Mozilla | 2024-11-30 |
This is a partial distrust: the roots were not removed outright, which would have broken every existing certificate at once. Instead, browsers stopped accepting new issuance while letting existing certificates run out naturally.
On 29 January 2025, Sectigo announced that it had acquired Entrust's public certificate business.
Who is affected
At the time, every Entrust TLS customer had to obtain certificates from another CA chain before their next renewal, because a new certificate under the distrusted roots would fail in Chrome, Safari and Firefox.
As of November 2026 the transition is complete. The maximum validity in 2024 was 398 days, so any certificate issued before the cutoffs had expired by early January 2026 at the latest. A server that still presents a certificate chaining to one of the affected roots is serving something Chrome will reject, typically with NET::ERR_CERT_AUTHORITY_INVALID.
Non-browser clients use their own trust stores and may behave differently from browsers, so API clients, Java applications and embedded devices should be tested separately.
What you should do
Replace any certificate whose issuer contains Entrust or AffirmTrust. Check who issued the certificate a server presents:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -dates
Use Certificate Transparency search to find every certificate issued for your domains and confirm none from the old hierarchy remains in use.
The broader lesson applies to any CA: keep a second CA ready, list both in your CAA records, and automate issuance with ACME so that switching CAs is a configuration change rather than a project. The root program decisions behind this and later events, such as the eMudhra compromise, are collected in the root program timeline.
FAQ
Are any pre-cutoff Entrust certificates still valid today?
No. With the 398-day maximum that applied in 2024, any certificate issued before the browser cutoffs had expired by early January 2026 at the latest.
Why do browsers use the SCT date instead of the certificate's start date?
The notBefore date is chosen by the CA and can be backdated. An SCT is a timestamp from an independent Certificate Transparency log, so it is much harder to manipulate.
Who took over Entrust's public certificate business?
Sectigo. On 2025-01-29 Sectigo announced that it had acquired Entrust's public certificate business.