By Yair Knijn · April 3, 2025

A browser distrusts your CA and gives you 90 days. Now what's your replacement plan?

Years ago your head of engineering picked a CA, wired it into the renewal tooling, and crossed it off the list. Ever since, the certificate has been treated like a power feed: permanent infrastructure nobody re-evaluates. The assumption buried in that choice is that the issuer stays trusted as long as the invoices get paid. That is not your decision to make. The browser root programs make it, and they can pull trust without asking you.

When they do, there is no renewal window. There is a deadline, and a count of how many certificates you have no tested way to move.

The Entrust distrust: how SCT dates turned a vendor into a deadline

In mid-2024, Google, Apple, and Mozilla each announced they would stop trusting public TLS certificates issued under Entrust roots, citing a loss of confidence in Entrust's issuance practices. The cutoffs landed within weeks of one another: Chrome after November 11, 2024, Apple after November 15, Firefox keyed to the earliest SCT dated past November 30. The mechanic is what bites. A certificate with a Signed Certificate Timestamp on or before your browser's cutoff keeps working, but the moment you rekey, modify, or renew it, the new SCT lands on the wrong side of the line and the cert goes dark. So the CA you can no longer renew from is also the CA whose existing certs you must not touch until you have already moved off it.

Why single-CA dependence is a concentration risk you can't price

Every other vendor risk in your stack has a knob. You can renegotiate the contract, escrow the source, stand up a second region, or absorb a price hike. A trust-store removal has none of that. No SLA survives a root-program decision, no support ticket reverses it, and no budget buys you back in on the old terms. The risk is binary and externally triggered, so you cannot price it the way you price an outage. What you can price is your recovery time: the days it takes to re-issue everything from a different issuer. If you have never measured that number, you do not know whether your exposure is 90 days of calm work or a 90-day fire you lose.

Designing for CA-agility: ACME, multi-issuer, and abstraction

CA-agility means the issuer is a configuration value, not an architectural assumption. The pattern is well-trodden, because Let's Encrypt forced the industry to standardize it, and the building blocks are mature:

• Issue through ACME wherever the CA supports it, so swapping providers is a directory URL and an account key, not a fresh integration.
• Keep an EAB-credentialed fallback issuer pre-provisioned and validated, so the second CA is one config flip away instead of a procurement cycle.
• Put a thin abstraction between your services and the issuer so no application code names a CA. The cert is a secret to be rotated, and nothing downstream should care who signed it.

You pay for this once, and the cost is small. You pay for not having it all at once, on someone else's schedule.

Tabletop: re-issuing your entire estate in 90 days

Run the drill before you need it. Take a non-production slice, point it at a different CA, and re-issue every certificate in it from scratch. The things your inventory hides will surface: a wildcard pinned in a mobile app, an internal service that hardcodes an issuer fingerprint, a load balancer that wants a manual upload, an OCSP stapling config tied to the old chain. Time it. Multiply by your real estate size and your real change-control friction, not the optimistic version. The output is one honest number, days-to-re-issue. If it is larger than the shortest distrust window a browser has ever handed out, you have work to do now, while it is still cheap.

Automate Certificates exists to keep that number small. Each Environment holds a live inventory of every certificate, its issuing CA, and its challenge type, issues through ACME against the CA you choose, and lets you re-point to a different issuer without rewriting a single integration. When the trust store shifts under you, swapping CAs is a config change you have already tested, not a discovery exercise. See how the multi-issuer model makes CA-agility the default.