# Entrust distrust: Chrome, Mozilla and Apple reject new certs

> Chrome 131+ distrusts Entrust/AffirmTrust TLS certificates whose earliest SCT is after 2024-11-11; Mozilla and Apple set their own cutoff dates.

Source: https://ssl.sh/news/entrust-distrust/
Last updated: 2026-11-10

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](https://ssl.sh/glossary/sct/) is dated after 2024-11-11 23:59:59 UTC. Using the [Certificate Transparency](https://ssl.sh/glossary/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](https://ssl.sh/glossary/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](https://ssl.sh/cas/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](https://ssl.sh/errors/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:

```bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates
```

Use [Certificate Transparency search](https://ssl.sh/tools/ct-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](https://ssl.sh/glossary/caa/) records, and automate issuance with [ACME](https://ssl.sh/glossary/acme/) so that switching CAs is a configuration change rather than a project. The [root program](https://ssl.sh/glossary/root-program/) decisions behind this and later events, such as the [eMudhra compromise](https://ssl.sh/news/emudhra-compromised-intermediate-cas/), are collected in the [root program timeline](https://ssl.sh/timeline/root-program-changes/).