Skip to content
Axelspire

CA Distrust Events: Entrust Case Study and Migration Playbook

When a browser vendor distrusts a public CA, certificates issued after the cutoff become untrusted—this playbook gives you a vendor-neutral migration framework, using Entrust (2024) and Symantec (2018) as reference cases.

CA Distrust Events: Entrust Case Study and Migration Playbook

Section titled “CA Distrust Events: Entrust Case Study and Migration Playbook”

TL;DR: CA distrust breaks trust for new issuance after vendor-defined cutoffs; you need fast blast-radius assessment, multi-CA strategy, and CA-agnostic automation—otherwise renewals on a distrusted CA fail while shorter public TLS lifetimes leave almost no runway.

Overview

Section titled “Overview”

A CA distrust event is one of the most disruptive incidents in certificate operations short of private key compromise. The certificate lifecycle practices you build today—inventory, automation, and multi-CA design—directly determine whether you recover in weeks or quarters.

Related context: Certificate rotation, renewal automation, inventory and discovery, and the 47-day TLS timeline (SC-081v3), which shrinks the time you have to react.

Problem Statement

Section titled “Problem Statement”
  • Trust is revoked for new issuance: After the cutoff, certificates with SCTs past the distrust date are untrusted; renewals with the same CA may fail policy.
  • Blast radius is unknown without inventory: Teams discover dependent systems only during the incident.
  • Single-CA concentration: 100% of certs with one CA maximizes impact of the next distrust.
  • Chain mistakes: New leaf certs with wrong intermediates cause validation failures.
  • Pinning and custom trust: HPKP (deprecated), app pinning, and hardcoded roots add migration work beyond re-issuance.

Failure scenario: Distrust is announced; CT and scans show 800 Entrust-backed endpoints; renewal is still pointed at the distrusted CA; production renewals start failing while leadership demands hourly status—without a runbook and second CA, mean time to recovery stretches to months.

The Entrust Distrust: Timeline and Mechanics

Section titled “The Entrust Distrust: Timeline and Mechanics”

The compliance failures

Section titled “The compliance failures”

Google’s Chrome team announced the distrust on June 27, 2024, citing a pattern of compliance issues over six years (mis-issuance interpretation of CA/B requirements, remediation-related mis-issuances, delayed revocations vs. Baseline Requirements, non-compliant customer extensions). The decision was framed as loss of confidence in Entrust’s ability to operate as a publicly trusted CA—not punishment for a single incident.

Distrust dates by browser

Section titled “Distrust dates by browser”
  • Google Chrome (131+): TLS certs with an SCT after 2024-11-11 23:59:59 UTC not trusted (Windows, macOS, ChromeOS, Android, Linux).
  • Apple Safari: TLS with SCT after 2024-11-15 not trusted; Apple’s scope also included S/MIME, timestamping, and BIMI.
  • Mozilla Firefox: TLS with SCT after 2024-11-30 not trusted.
  • Microsoft: As of early 2026, no equivalent distrust announcement for Entrust roots in Microsoft’s store.

Nine Entrust-related roots were in scope (including AffirmTrust roots Entrust had acquired).

Entrust’s response and business transition

Section titled “Entrust’s response and business transition”
  1. ERA with SSL.com: External Registration Authority—SSL.com validated and issued from its roots while Entrust handled customers.
  2. Sale to Sectigo: Public TLS business sold; ECS portal moved to Sectigo-rooted issuance; migration tooling in portal.
  3. Issuance stop: Public TLS from Entrust roots ended 2025-03-11; portal migration window until 2025-09-08. Private PKI, CLM, signing, and PQC businesses retained.

The Migration Playbook (any CA)

Section titled “The Migration Playbook (any CA)”

Phase 1: Blast radius assessment (days 1–3)

Section titled “Phase 1: Blast radius assessment (days 1–3)”

Certificate inventory: Every cert from the affected CA—subdomains, APIs, internal services using public trust, SaaS on your domains, CDNs, load balancers. Use CT (e.g. crt.sh), openssl s_client sweeps, and your CLM / inventory data.

Terminal window
# CT-style query example (adjust domain and issuer filter)
curl -s "https://crt.sh/?q=%.yourdomain.com&output=json" | \
  jq '.[] | select(.issuer_name | test("Entrust")) |
  {id: .id, name: .name_value, not_after: .not_after}'


openssl s_client -connect your-service.com:443 -servername your-service.com \
  </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

Categorize: Critical (expires inside distrust window), moderate (valid but cannot renew on same CA), low (limited exposure).

Hard dependencies: Custom trust stores, pinning configs, OCSP stapling tied to specific intermediates.

Phase 2: CA selection and accounts (days 3–7)

Section titled “Phase 2: CA selection and accounts (days 3–7)”

Do not move 100% to a single new CA. For DV, consider Let’s Encrypt, Google Trust Services, or any ACME CA. For OV/EV, plan 1–5 business days for org validation—complete it before you need certs. See ACME clients and automation readiness.

Phase 3: Replacement (days 7–90)

Section titled “Phase 3: Replacement (days 7–90)”
  1. Prefer new key material unless policy allows reuse and keys are clean.
  2. CSR with same SANs / subject.
  3. Order via ACME, API, or portal.
  4. DCV does not transfer—re-validate with the new CA.
  5. Install full chain for the new CA (common failure: old intermediates).
  6. Test with Chrome, Firefox, Safari, curl, openssl s_client.
  7. Revoke old certs once new ones are live.
Terminal window
# Example: move DV to Let's Encrypt (illustrative)
sudo certbot certificates
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/certbot/cloudflare.ini \
  -d your-service.com -d '*.your-service.com' \
  --cert-name your-service.com
openssl x509 -in /etc/letsencrypt/live/your-service.com/cert.pem -noout -issuer -dates
sudo systemctl reload nginx

Phase 4: Validation and monitoring (ongoing)

Section titled “Phase 4: Validation and monitoring (ongoing)”

External checks on all public names, ACME logs, alerts before late renewal, periodic CT review for shadow issuance.

Architectural lessons

Section titled “Architectural lessons”
  • Multi-CA: At least two relationships with validated automation (e.g. LE for DV + commercial for OV/EV).
  • CA-agnostic automation: Standardize on ACME (RFC 8555) where possible—not a single vendor’s portal API only.
  • Inventory as infrastructure: Queryable in minutes after an announcement.
  • Runbook: Owners, pre-approved alternate CAs, credential locations, priority order, comms—drill annually.

Historical context

Section titled “Historical context”
EventOutcome
DigiNotar (2011)Full distrust; fraudulent google.com certs; CA failed commercially.
Symantec (2017–2018)Phased distrust; sale to DigiCert; long runway but many late migrations.
Entrust (2024–2025)~5 months to first Chrome cutoff; sale to Sectigo; shorter than Symantec.

Pattern: years of issues → warnings → distrust with months of runway → exit or sale. No CA is immune.

The 47-day intersection

Section titled “The 47-day intersection”

Under SC-081v3, short lifetimes mean little “grace” from old certs—you need the same pipeline that does routine renewal to switch ACME directory URL or issuer without a rebuild. That is the core argument for CA-agnostic automation.

Operational checklist

Section titled “Operational checklist”
  • CT + scan + CLM export merged into one inventory with owner and renewal path
  • At least two CAs validated for production issuance
  • ACME (or API) tested end-to-end including deploy hooks
  • No production dependency on a single CA’s proprietary-only workflow
  • Distrust runbook written and tabletop-tested
  • Chain installation verified on a pilot before mass cutover
Section titled “Related documentation”