Switch certificate authority: a plan B for TLS certificates

Why a certificate authority can suddenly drop out

Whether a browser trusts a website certificate is not decided by the certificate authority but by the root program of the browser or operating system. It maintains a trust store (root store) with the root certificates it accepts and reserves the right to change that set. The Chrome Root Program policy says so explicitly: Google includes or removes certificates in the Chrome Root Store at its sole discretion (Chrome Root Program Policy). Mozilla's root store policy contains a corresponding clause for the store used by Firefox and many other programs (Mozilla Root Store Policy).

October 2026 showed how fast this can happen. On October 17, the Chrome Root Program received a report that the private keys of several intermediate certificates of one certificate authority had been generated with insufficient randomness (Google). Chrome blocked the affected intermediates the same day through its own blocklist (Google). On October 20, Google announced that it would also remove the corresponding root from the Chrome Root Store and named October 27 as the date (Google). That left seven days between announcement and scheduled removal (Google).

For site operators, another sentence mattered most: some legitimately issued certificates under this root stop working in Chrome as well, and anyone affected must immediately obtain and install a new certificate from a different hierarchy (Google). This also hit websites with a valid certificate, a complete chain and enough remaining validity; only the trust anchor at the top was due to be removed.

On top of that comes an obligation that applies even without a root removal. The baseline rules for publicly trusted TLS certificates require certificate authorities to revoke issued certificates within 24 hours under certain circumstances (CA/Browser Forum). The forum infers from this that certificates are meant to be managed so they can be replaced within 24 hours (CA/Browser Forum). How a revocation reaches the browser today is covered in the article on certificate revocation after the end of OCSP.

Planned changes: age limits and fewer roots

Besides emergencies, root programs change their stores according to fixed rules. The most important one is an age limit: Chrome removes root certificates whose key material was generated more than 15 years ago from the Chrome Root Store on an ongoing basis (Chrome Root Program Policy). Mozilla removes the websites trust bit from root certificates for server authentication once their key material is more than 15 years old (Mozilla Root Store Policy). For older roots, Chrome has published a phased schedule (Chrome Root Program Policy):

For other cases, the policy describes a gentler procedure, the phase-out of a hierarchy: certificates issued before the cut-off date remain trusted in Chrome until they expire, while certificates issued later are no longer trusted by default (Chrome Root Program Policy). For operators, this means that the next renewal may come with a chain from a new hierarchy even if they did not switch certificate authorities. Anyone who hard-coded the chain in the server configuration then serves the wrong one.

A second rule shrinks the store further: from September 15, 2027, the Chrome Root Store will include at most two self-signed root certificates per CA owner (Chrome Root Program Policy). Even without an incident, some certificates will therefore change their hierarchy over the next few years, and with it the chain the server delivers.

How much a store moves is visible in the copy of the Mozilla store that the curl project provides as a file for programs without a trust store of their own. The version of March 19, 2026 contained 145 certificates, the version of May 14, 2026 only 121 (curl). Anyone who copies such a file into an application once and does not update it afterwards checks against a state that no longer exists.

Who trusts which store

A certificate is not valid on its own; it is valid for a particular client. On Windows, macOS, ChromeOS, Linux and Android, Chrome checks against its own Chrome Root Store and does not rely on the operating system's default store (Chrome Root Store FAQ). On iOS, Apple's policies do not allow this (Chrome Root Store FAQ). Firefox uses the Mozilla store, and tools such as curl obtain a copy of it (curl). Java runtimes, mobile apps, payment terminals and Internet of Things (IoT) devices may ship their own bundles.

As a result, a root can be missing from one store and still be present in another. In routine operation, the Chrome Root Store is updated approximately quarterly, with off-cycle updates when needed, and the changes reach users through a separate update mechanism without a new browser version (Chrome Root Store FAQ). Other stores follow their own rhythm: an operating system update, a Linux distribution package, a new app version. A device that no longer receives updates keeps its state.

How long old stores linger was documented by a large ACME CA when it moved to its own root. In late 2021, more than a third of Android devices were still running operating system versions that would suddenly have stopped trusting websites with this CA's certificates (Let's Encrypt 2023). In the three years up to July 2023, the share of Android devices trusting the new root rose from 66 to 93.9 percent (Let's Encrypt 2023). Android 14 can update its trust store without a full operating system update (Let's Encrypt 2023).

For APIs, this transition came with its own checklist: all clients of an API had to know the new root, and clients using OpenSSL needed at least version 1.1.0 (Let's Encrypt 2021). No browser test sees these clients. The article The site works for us, not for the customer shows how to narrow down such differences between two environments, and the article on the incomplete certificate chain explains why a browser forgives what an application rejects.

Step 1: Know who issues your certificates

A plan B starts with an inventory. For every hostname with a public certificate you need three facts: the issuing certificate authority, the root the chain ends at, and the way the certificate is renewed. Without this list, there is no quick answer to whether a report like the one in October affects you.

The tricky part is rarely the main domain but rather subdomains set up by a service provider, a department or an earlier project, such as the interface to the merchandise management system or a test system. Certificate Transparency helps here: since June 15, 2026, certificate authorities under the Chrome Root Store must log every precertificate to at least one CT log recognized by Chrome before issuing the certificate (Chrome Root Program Policy). The logs thus reflect the publicly trusted certificates for your domain, including the forgotten ones. How to evaluate them is described in the article on monitoring CT logs.

• Hostname and purpose: www, shop, interfaces, test systems, redirect domains.
• Issuer and root: issuing certificate authority, intermediate certificate and the root certificate at the end of the chain.
• Renewal path: ACME client and account, hosting control panel, upstream network or manual work.
• Responsibility: who renews the certificate and who decides when a report comes in.
• Clients outside the browser: apps, partner interfaces and devices that call the hostname.

The chain details for each hostname can be read with a single command. The output shows the subject (s) and the issuer (i) for every link in the chain; the issuer of the last link is the root the chain ends at.

In day-to-day operation, SSL monitoring by XICTRAQ® takes this over. The SSL tab shows issuer, validity and chain of trust, and a website scan also reads chain length and root CA (XICTRAQ documentation). The history marks an issuer change as a separate event and goes back up to 90 days (XICTRAQ documentation). From the Business plan, XICTRAQ® additionally keeps an inventory of all certificates issued for your own domain according to the CT logs, with issuer and expiry date per certificate; details are on the DNS and domain monitoring page.

Step 2: CAA with room for a second CA

A CAA record in DNS defines which certificate authorities may issue for a domain. Before every issuance, a certificate authority must look for this record; if it exists and the request does not match it, the authority must not issue (RFC 8659). That protects against unauthorized issuance but becomes a trap when switching: if you list only your current certificate authority, you block exactly the fallback path in an emergency.

The standard explicitly provides for several permitted issuers. Its own example allows issuance for a hostname by only two specific certificate authorities (RFC 8659). Authorizations are additive, and every issue record permits one more authority (RFC 8659). A separate issuewild record can apply to wildcard certificates, and iodef names an address to which certificate authorities can report rejected requests.

; primary CA and prepared fallback CA
example.invalid.  3600  IN  CAA  0 issue "ca1.example.net"
example.invalid.  3600  IN  CAA  0 issue "ca2.example.org"
; without issuewild, the issue records also cover wildcards
; reports of rejected requests
example.invalid.  3600  IN  CAA  0 iodef "mailto:pki@example.invalid"

If you also want to bind issuance to a specific account, use the accounturi parameter (RFC 8657). It applies per record: if it names an account at a different certificate authority than the one in the record, the record is unsatisfiable (RFC 8657). For plan B, this means creating the fallback account in advance and writing its identifier into the second issue record. The Chrome Root Program requires certificate authorities with an ACME interface to support this account binding (Chrome Root Program Policy). More on the records and on securing them with DNSSEC is in the article on CAA records and DNS hardening.

XICTRAQ® queries DNS records including CAA every 6 hours on paid plans and every 24 hours on the Free plan (XICTRAQ feature page). Every change to the CAA set triggers an alert, with the removal of any restriction as critical, and the assessment shows whether the records cover the issuer of your active certificate (XICTRAQ documentation). If the CAA set no longer matches the active issuer, for example because only the old record was restored after a switch, it shows "Issuer not covered", and the next renewal with that authority would not be permitted. Details are in the manual under DNS and email.

Step 3: Prepare an ACME fallback path

A plan B is only as fast as issuance at the second certificate authority. With the Automatic Certificate Management Environment (ACME), issuance can be triggered without manual work, provided account, validation and deployment are set up in advance. The conditions for this are improving: from March 15, 2027, all valid intermediate certificates under a root in the Chrome Root Store must be integrated with an automation solution, ACME or a comparable method (Chrome Root Program Policy). If a hierarchy supports ACME, it must also offer ACME Renewal Information (Chrome Root Program Policy).

1. Choose a second certificate authority: from a different hierarchy, with ACME and with a root your most important clients know. Organization-validated certificates need lead time for verifying company details.
2. Create the account and add it: register the ACME account with the second authority and add it to CAA, including accounturi if you use account binding.
3. Test issuance: obtain a real certificate once on a test system or test subdomain, including validation via HTTP or DNS.
4. Take the chain along: configure the ACME client to fetch the certificate authority's chain with every issuance and not to serve a hard-coded chain.
5. Document the switchover: which configuration changes, who reloads the service and how the new chain is checked from the outside.

The fourth point sounds obvious, but it is not. When rebuilding its chain, one certificate authority listed the failure modes it had seen in ACME clients: the chain was not downloaded at all and only the website certificate was served, the chain was not downloaded and a hard-coded one was served instead, or the chain was fetched only at first issuance and not on renewals (Let's Encrypt 2023). Each of these errors produces an invalid chain when switching to another certificate authority, because the old chain does not match the new certificate.

As a short file next to the server configuration, the fallback path can look like this:

hostnames:
  - www.example.invalid
  - shop.example.invalid
  - api.example.invalid
primary_ca:
  acme_directory: https://acme.ca1.example.net/directory
  caa: "ca1.example.net"
fallback_ca:
  acme_directory: https://acme.ca2.example.org/directory
  caa: "ca2.example.org"
  account_created: 2026-11-08
  test_issuance: test.example.invalid, 2026-11-10
switchover:
  owner: operations, on-call
  reload_service: systemctl reload nginx
  external_check: openssl s_client -showcerts
other_clients:
  - iOS and Android app
  - partner interface, merchandise management

The ACME Renewal Information extension is more than a convenience for plan B. It lets the certificate authority suggest an earlier renewal time to clients, for example ahead of a mass revocation, to reduce its impact (RFC 9773). A client that evaluates these hints then renews in time with the current authority. If the authority itself loses trust, only the second account helps. How to test renewal as a whole is described in the articles on testing ACME renewal and on SSL automation with ACME.

Shorter lifetimes turn the fallback path into the normal case. The CA/Browser Forum decided to reduce the maximum validity of public TLS certificates from 398 to 47 days (CA/Browser Forum), in steps from March 2026 to March 2029 (CA/Browser Forum). If you renew every few weeks anyway, you can treat a change of certificate authority like an ordinary renewal, provided the second path has worked once.

Step 4: What else breaks during a switch

Even if the new certificate is valid in every browser, clients outside the browser can fail on it. Four spots deserve particular attention.

Client authentication has a fixed date: website certificates under roots in the Chrome Root Store that are issued on or after March 15, 2027 may only assert server authentication as their purpose (Chrome Root Program Policy). If you currently also use a website certificate for mutually authenticated connections, you will need another path for that by then at the latest, regardless of whether you switch certificate authorities.

A browser is not enough to check the clients; a sensible approach is to test the clients from step 1 against a certificate from the fallback authority on a test system. The free SSL check shows from the outside which issuer chain a server delivers and which TLS version it negotiates. Whether a specific app trusts the new root can only be clarified with that app.

The sequence on day X

When a report like the one in October arrives, the order matters. With a prepared plan B, it looks like this:

1. Check whether you are affected: look up in the inventory which hostnames depend on the named root or intermediate.
2. Read the deadline: does the change apply to new or also to existing certificates, and from when in which client?
3. Trigger the fallback authority: issue certificates for the affected hostnames through the prepared account.
4. Deploy: install certificate and chain, reload services, include load balancers and upstream networks.
5. Check from the outside: verify chain, root and hostnames externally, then the clients outside the browser.
6. Follow up: update CAA, inventory and responsibilities.

Without preparation, more steps come on top of these six: opening an account with a new certificate authority, changing CAA and waiting for resolvers, setting up validation for the first time, getting internal approval. That can fit into a deadline of seven days (Google), but hardly into one of 24 hours (CA/Browser Forum).

What XICTRAQ® sees and what it does not

Monitoring does not replace a plan B, but it shows where one is needed and whether it worked. XICTRAQ® checks validity, issuer, protocol and remaining validity continuously, every 6 hours on paid plans and every 24 hours on the Free plan (XICTRAQ documentation). If the chain check fails, XICTRAQ® raises a separate critical alert, independent of the expiry warning (XICTRAQ documentation). You choose the channels it uses to reach you under alerting and notifications.

What matters is which store the check uses. XICTRAQ® validates the chain against the Mozilla root bundle of the checking server (XICTRAQ documentation). How current that store is depends on the server's system package. If only Chrome removes a root from the Chrome Root Store while it is still in the Mozilla store, this check does not see the loss of trust, and XICTRAQ® keeps reporting the certificate as valid.

What XICTRAQ® contributes is knowledge of your inventory. With it, you can narrow down which hostnames depend on which hierarchy when a report comes in, and prove after the switch that the new chain is being served. The manual describes all fields under SSL and TLS.

Prepare plan B while no deadline is running

A change of certificate authority is easiest to prepare while nobody is forcing it. The building blocks are manageable: an inventory list, a second CAA record, an account with a second authority and one test issuance. After that, a loss of trust in a root program is a date in the calendar rather than a night shift.

If you do not want to maintain the inventory by hand, you can have issuers, chains and CAA records of your websites monitored by XICTRAQ®. What each plan includes is on the pricing page; the live demo shows what the SSL tab and certificate inventory look like, without signing up.