Chrome Stops Trusting New Entrust Certificates: Check Your Chain This Week

If your organisation buys TLS certificates from Entrust, last Thursday was a deadline. Back in June, the Chrome Root Program announced that Chrome would stop trusting TLS server certificates issued from Entrust's public roots if their earliest Signed Certificate Timestamp (in effect, their issuance date) is after October 31, 2024. That date has now passed.

Certificates issued on or before October 31 keep working until they expire. A new Entrust certificate issued this month will produce an error in Chrome. That makes this a slow-motion change: nothing broke on November 1, but every Entrust certificate you renew from now on is a potential outage, and the renewals will arrive at whatever pace your certificates expire over the next year.

Why Chrome did this

Browsers don't remove a major CA lightly. Chrome's announcement pointed to a pattern of compliance incidents over several years, and to commitments to improve that, in Chrome's view, weren't met. Public discussion on the Mozilla and CA/Browser Forum lists over the preceding months had documented a series of mis-issuance incidents and slow or disputed responses to them.

Chrome wasn't alone for long. Mozilla announced a similar distrust for its products with a slightly later cutoff, and other root programs have been weighing their own positions. The exact dates and scope differ by browser and platform, so if you have a mixed client population, check each vendor's announcement rather than assuming Chrome's date applies everywhere.

The detail that matters for operators: this is about new issuance, not a sudden revocation. Existing certificates aren't being pulled. You get a controlled migration, as long as you do it before each certificate's renewal date.

Step 1: find your Entrust certificates

Certificate Transparency logs are the quickest way to see what's been issued for your domains:

# Currently valid certificates for a domain, with issuer and expiry
curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | \
  jq -r '.[] | [.not_after, .issuer_name, .name_value] | @tsv' | \
  grep -i entrust | sort -u

Then confirm what your endpoints actually serve, since issued and deployed aren't always the same:

for host in www.example.com api.example.com mail.example.com; do
  echo -n "$host: "
  echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null | \
    openssl x509 -noout -issuer -enddate | tr '\n' ' '
  echo
done

Don't stop at the website. Entrust certificates are common in enterprise settings, so check mail servers, VPN gateways, API endpoints, load balancers and anything on a non-standard port.

Step 2: plan each renewal

For every Entrust certificate you find, write down its expiry date. That date is now your migration deadline for that certificate. A certificate expiring next August gives you time; one expiring in three weeks does not.

When you move to a new CA:

• Update your CAA records first. If your domain has CAA records listing only Entrust, the new CA is required to refuse to issue. Add the new CA's identifier before you request anything.

  example.com.  CAA 0 issue "letsencrypt.org"
  example.com.  CAA 0 issue "digicert.com"
  

• Budget for validation. A new CA means new domain validation, and for OV or EV certificates, new organisation validation. That can take days.

• Serve the full chain. Different CA, different intermediate. Make sure your servers send the new intermediate, not a leftover Entrust one. Missing intermediates often work in desktop Chrome and fail in other clients, which makes them easy to miss in testing.

• Check anything that pins. Mobile apps, API clients and partner integrations sometimes pin to a specific CA or intermediate. A pin to Entrust's key will break the moment you switch. Find those before the renewal, not after.

Step 3: consider automating while you're at it

A forced CA change is a good time to fix how certificates get renewed. If you're re-validating domains and updating configs anyway, moving to an ACME-based CA (Let's Encrypt, or a commercial CA that supports ACME) means the next renewal happens without anyone touching it.

That matters beyond this event. Google has been signalling for over a year that it wants shorter certificate lifetimes, and each reduction makes hand-renewed certificates more expensive to maintain. Moving from one manual CA to another manual CA solves this week's problem and leaves the next one in place.

A note on internal and enterprise use

Chrome's announcement notes that enterprises can keep trusting Entrust certificates on managed devices by explicitly installing the relevant roots as locally trusted. That may be a sensible stopgap for internal applications with a known set of managed clients. It isn't a fix for anything public-facing: you can't install roots on your customers' machines.

The bigger lesson: your CA is a dependency

Most teams treat their certificate authority as a commodity. This week is a reminder that the CA is a third-party dependency like any other, one whose standing with the browsers is outside your control. It's the same shape as the polyfill.io incident earlier this year: something you relied on quietly changed status, and the only defence was knowing where you used it.

A few habits that make the next CA change routine:

• Keep an inventory of certificates, with issuer and expiry, generated from CT logs and endpoint checks rather than memory.
• Keep CAA records deliberate and up to date, with more than one acceptable CA if your policy allows.
• Make sure every renewal path could switch CA without a redesign.
• Watch the certificates your endpoints serve, including issuer changes. An unexpected issuer on a production hostname is worth an alert.

Keep an eye on what you serve

The migration itself is straightforward. The risk is the certificate nobody remembers, expiring on a quiet Friday next spring and getting renewed from habit with a CA that browsers no longer trust. Expiry and issuer monitoring from the outside, with CompleteStatus or whatever tool you prefer, turns that into a routine alert instead of a customer-facing error.