What happens if a browser stops trusting your certificate authority?

If a browser distrusts a certificate authority, sites using its newer certificates show a full page warning in that browser. Existing certificates may keep working for a period, depending on how the browser phases it in. Prepare by knowing which CA issued each certificate and by being able to replace them quickly.

A documented example

In June 2024 the Chrome Root Program and Chrome Security Team published a post announcing that Chrome would stop trusting certain public CA roots by default. The post said the decision followed a pattern of compliance failures and unmet improvement commitments seen over several years. A later update moved the start of blocking to November 12, 2024, aligned with Chrome 131.

The mechanism is worth understanding. Chrome did not block every certificate from those roots at once. Certificates whose earliest Signed Certificate Timestamp was dated on or before November 11, 2024 were unaffected. Certificates issued after that date would trigger a full page interstitial in Chrome versions 131 and later on Windows, macOS, ChromeOS, Android and Linux. The post notes that Chrome on iOS is not covered by this mechanism because of Apple policy.

The post also said certificates from other CAs were not affected, and that website owners could check their certificate's issuer in the Chrome Certificate Viewer. It recommended that affected operators move to a different publicly trusted CA before existing certificates expire, if expiry fell after the cutoff.

What this teaches about continuity

Nothing in that event was an outage in the usual sense. Servers stayed up. The risk was a sudden change in what browsers would accept for new certificates, with a published date. The lesson is not to fear one CA. It is to avoid a setup where you cannot change CAs without scrambling.

A preparation checklist

1. Inventory every public certificate you use, including those on load balancers, CDNs, APIs, mail servers and vendor-hosted pages. Record the issuing CA and expiry.
2. Find where renewal is automated and where it is manual. Manual ones are where a deadline hurts.
3. Check that your automation is not hard-wired to one CA. Where the protocol lets you configure the issuer, make that a setting, not code.
4. Keep an account with a second public CA ready, or know how long it would take to open one.
5. Keep CAA records and any pinning in mind. DNS records that restrict issuance to one CA will block issuance from another until you change them. If you pin certificates or keys in mobile apps, see how you would rotate them.
6. Rehearse once. Replace a low risk certificate with one from a different CA and note what broke.
7. Watch for official announcements from browser root programs and your CA, and assign someone to read them.

Testing without risk

The Chrome post described a command line flag, added in Chrome 128, to simulate the effect of a distrust constraint for testing. If you ever face a similar announcement, check the current browser documentation for how to test in your own environment before the date arrives.

A worked example: auditing certificates in one afternoon

This example is hypothetical. A small company suspects its certificates are scattered across systems. It sets aside an afternoon to build a certificate register.

Three observations come out of a table like this. First, two public CAs and a private one are in use, so a change by any one browser affects some hostnames, not all. Second, two renewals are manual, which is where a deadline would hurt. Third, one certificate is held by a vendor, so the team needs to know who to ask and how long a change would take.

Step by step: how to build the register

1. Pull a list of hostnames from DNS, your load balancers and your CDN. Add names from vendor hosted services you point your domain at.
2. For each hostname, connect and read the certificate: issuer, validity dates and the chain. Certificate transparency logs can help you discover certificates issued for your domains that you had forgotten.
3. Record the renewal method. Automated renewal through a standard protocol is easy to repoint. Manual renewal needs a calendar entry and a named person.
4. Record how a certificate would be replaced and how long that takes, from the first request to being live.
5. Mark anything that pins a certificate or key, such as mobile apps and partner integrations. Pinned items are the hardest to change quickly.
6. Review CAA records in DNS. If they permit a single CA, add a task to change them before any move, or issuance from a new CA will fail.
7. Set an owner and a review date for the register.

Questions to ask your CA and your customers

Ask your current CA how it announces incidents and policy actions, and where you can read about them. Ask whether your plan includes tools to switch issuers. If you provide certificates or endpoints to customers, tell them which names matter and what to expect if you change issuers. Customers that pin your certificate will need notice well in advance.

Keep proportion

The Chrome post is one documented example, with a published date and rules. Most teams will never need to act on such an event, and many will see a long lead time if they do. The aim of the register is not to predict a problem. It is to make a calm response possible whatever the cause, whether a distrust action, a CA incident or a simple expiry. Our post on certificate expiry outage prevention covers the most common cause of certificate trouble.

Try it yourself

Open the continuous monitoring demo and look at how ongoing checks surface a change over time. A certificate register is more useful when something watches for expiry and issuer changes in the same way.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Chrome Root Program: Sustaining Digital Certificate Security, Google Online Security Blog, 27 June 2024

Last reviewed: 19 October 2026.