Entrust Certificates Distrusted by Chrome: What Site Owners Do

Chrome will stop trusting Entrust certificates issued after October 31, 2024. So if you run sites on Entrust, inventory what you have and move new issuance to another certificate authority before the next renewal. The cutoff is days away. Still, nothing breaks overnight: according to the Chrome Root Program announcement on Entrust, certificates already in place keep working. A planning job, then. Not an emergency.

What does the Chrome Entrust distrust actually change?

Chrome 131 and later will no longer trust TLS certificates that chain to Entrust roots when they were issued after October 31, 2024. Google lays out the scope in its Security Blog post about the distrust. And here is the bit people get wrong: the rule hangs on the issuance date, which Chrome reads from the earliest Signed Certificate Timestamp embedded in the certificate. The day a visitor loads the page? Irrelevant. Why is Google doing this at all? It cites a pattern of compliance failures, unmet improvement commitments and a lack of measurable progress in response to publicly disclosed incident reports, all of which eroded its confidence in Entrust as a CA owner.

Which Entrust certificates keep working and which will fail?

Issued on or before the cutoff: trusted until expiry. Issued afterwards: a browser warning in affected Chrome versions. And it is not a subtle one, because a visitor who hits a distrusted certificate gets a full-page interstitial instead of the site. The exceptions listed by Google are narrow: enterprises can explicitly trust the affected roots through local trust settings on machines they control (which does nothing for public visitors).

In practice, a renewal or reissue after the deadline is the moment a site breaks. So your renewal calendar sets the real deadline for each domain. One trap here: a reissue triggered by a key rotation or a hostname change counts just like a scheduled renewal.

How to find every Entrust certificate you run

Check the issuer and the issuance date of each certificate on every hostname, including the ones not served from the main web server. Forgotten endpoints are where the surprises come from. Go through:

• main sites and all subdomains
• load balancers and proxies that terminate TLS
• mail and API endpoints
• staging and test hosts
• certificates bought through a hosting provider or reseller, where the issuer may not be obvious from the invoice

For a single site, the browser’s certificate viewer shows both fields. Got a batch? Run this against each host from your own machine:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -issuer -dates

Write down the hostname, issuer, issued date, expiry date, where the private key lives and who renews it. Boring, I know. But if you are pointing DNS at a proxy for some domains, also note which machine actually presents the certificate to visitors, because that is the box you will be updating.

How to replace an SSL certificate with one from another authority

Generate a new key and CSR, get the certificate issued by a different publicly trusted CA, install it with the full chain and reload the web server. All of it before the old one needs renewing. On your own server or with your provider, the sequence goes like this:

1. Pick the new CA and the validation type you need.
2. Create a fresh private key and CSR on the origin.
3. Complete domain validation by DNS, HTTP or email.
4. Install the certificate and intermediate chain in the NGINX or other server config.
5. Test the configuration, then reload rather than restart.
6. Verify from outside with a browser and the openssl command above.

Leave the old certificate where it is until the new one is verified. The swap itself needs no downtime, so there is no reason to rush it. And since you are changing the certificate authority anyway, my advice is to drop manual purchases while you are at it and go with automated ACME issuance on your origin. One catch: when that origin sits behind another layer, validation requests have to reach it. We cover that setup in our guide to Let’s Encrypt behind proxies.

Update the CAA DNS record before you request the new certificate

A CAA DNS record lists which certificate authorities may issue for a domain. Skip adding the new CA there and issuance gets refused. Simple as that. CAA stands for Certification Authority Authorization, and an entry permitting a new issuer looks like this:

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

See what exists with dig CAA example.com for the apex, then again for each subdomain, because a name without its own record inherits the policy of its parent. Order matters. Add the new authority first, issue and deploy, and only then remove the Entrust entry once no hostname depends on it. Validation failing right after an edit? Wait for the record’s TTL to pass before you retry.

Certificate errors and SEO: what a missed renewal costs

A distrusted certificate puts a warning page between you and your visitors. Traffic and conversions drop right away, even though the server itself is still responding. That is the nasty part. Unlike a crash, the origin keeps returning content, but Chrome users never reach it, so uptime checks that ignore trust will happily report everything as healthy. Compare that with what visitors get during outages, where a status code at least tells clients something went wrong.

What to expect: abandoned visits, failed checkouts and form submissions, plus broken API or webhook calls from clients that validate the chain. Prevention is cheap, though. Monitor expiry and issuer for every hostname, set a renewal reminder well ahead of each date, and test in current Chrome after any certificate change.

A switch plan for Entrust certificates across several sites

Sort your sites by renewal date and migrate the earliest ones first. Within that order: certificates expiring soonest, then revenue-critical hosts, then internal and staging names. For each site there is a decision to make. Reissue with Entrust before the cutoff to buy time until that certificate expires? Or move straight to the new CA and be done with it?

Write down the new renewal owner and the automation behind it, so nobody has to repeat the migration by hand next year. And the one action for this month is simple: list all your Entrust certificates with their issued and expiry dates, and assign a replacement authority to each before its next renewal comes up.

FAQ