Multi-CA Strategy: Why Issuer Redundancy Isn't "Buy Two Vendors"
In June 2024, Google's Chrome Security Team announced that Chrome would no longer trust new TLS certificates from Entrust, citing six years of compliance failures and unmet improvement commitments. Apple and Mozilla followed within months. By November 2024, certificates from Entrust issued after the distrust dates triggered browser security warnings — "Your connection is not private" — for any site that hadn't migrated to a different CA.
Major enterprises were running on Entrust. ServiceNow scrambled to replace certificates across their platform. Financial institutions, government agencies, and technology companies that had standardised on Entrust faced emergency migration timelines. AppViewX research found that over 20% of Fortune 1000 companies were using Entrust as a CA. For organisations with thousands of certificates, the migration wasn't a weekend project — it was a multi-month operational exercise under pressure.
This wasn't the first time it happened. In 2018, Google deprecated Chrome's trust in Symantec's certificate authority following security concerns. The playbook was the same: detect, panic, migrate, promise to do better.
PKI Health Radar
Drag the sliders to assess your current posture — scores update instantly.
The lesson both incidents teach is the same: single-CA dependency is a supply chain risk. And like most supply chain risks, organisations ignore it until the supply chain breaks.
The Single-CA Risk You're Carrying
Most organisations end up with a single CA not by strategic choice but by historical accident. Someone chose a CA years ago, it worked, and the relationship calcified. The commercial agreement, the ACME integration, the team's familiarity with the portal — all of these create switching costs that accumulate silently.
The risk isn't just CA distrust events, though those are the most dramatic. Single-CA dependency exposes you to: CA operational outages (issuance infrastructure goes down during a critical renewal window), commercial disputes (pricing changes, contract terms, acquisition by a company your procurement team won't approve), regulatory changes (new compliance requirements that your CA doesn't meet for specific certificate types), and validation delays (CA validation infrastructure backlog during peak issuance periods).
When the 47-day certificate validity timeline hits in 2029, your certificate renewal frequency increases roughly eightfold. If your single CA has an outage during a renewal cycle, the blast radius is your entire certificate estate. Multi-CA isn't a nice-to-have when renewal frequency is monthly — it's the difference between a localised disruption and a company-wide TLS outage.
Multi-CA Is Not "Buy Two Vendors"
The naive response to CA risk is to sign contracts with two CAs. This addresses precisely one failure mode — total CA distrust — while creating new operational problems.
Without policy-driven routing, a second CA means: two sets of API integrations to maintain, two validation workflows to manage, two billing relationships, two certificate inventories that may or may not be consolidated, and no automated logic for deciding which CA issues which certificate. When the primary CA has an issue, someone has to manually switch issuance to the secondary — and "someone" usually means the engineer who happens to be on call at 2am.
The strategic architecture for multi-CA has three models, and the right one depends on your organisation's scale and certificate estate characteristics.
Primary/secondary failover. One CA handles all issuance by default. The secondary CA is pre-configured and tested but only activated when the primary is unavailable or distrusted. This is the simplest model. The risk is that the secondary CA integration rots — configuration drift, expired API credentials, untested validation workflows — because it's never used in production. Failover that isn't regularly tested isn't failover.
Use-case routing. Different CAs handle different certificate types based on their strengths. Public CA A handles web-facing DV certificates because they have the fastest ACME issuance. Public CA B handles OV and EV certificates because they have superior validation workflows for your corporate entity structure. Private CA handles internal service certificates. This model is operationally clean because each CA has a defined purpose, and the routing logic is stable.
Active-active with policy routing. Both CAs handle the same certificate types, with issuance distributed based on policy rules: geographic proximity of validation infrastructure, cost per certificate, compliance requirements, or even load balancing across CAs. This is the most resilient model but requires automation infrastructure that can make CA-selection decisions per issuance request.
All three models require automation. You cannot run multi-CA manually at any meaningful scale. ACME protocol support from both CAs is effectively mandatory, because manual certificate request processes don't translate across CA portals without significant human intervention.
CA Selection Criteria Beyond Price
When evaluating CAs for a multi-CA architecture, the criteria that matter aren't the ones on the RFP template.
ACME support and API maturity is the first filter. If a CA's ACME implementation is non-standard, slow, or unreliable, your automation breaks. Test issuance speed, renewal reliability, and error handling before committing. Some CAs have excellent web portals and terrible APIs.
Validation speed and reliability becomes critical at 47-day lifetimes. When domain control validation must happen with nearly every issuance (the DCV reuse period drops to 10 days by 2029), a CA with slow or unreliable validation infrastructure creates renewal risk. Test DNS-based and HTTP-based validation under realistic conditions.
Compliance certifications matter for regulated industries. Some CAs carry specific certifications (WebTrust, ETSI) that your auditors require. Ensure your secondary CA meets the same compliance bar as your primary.
Revocation handling differentiates CAs for non-web use cases. For code signing or client certificates where revocation actually matters, evaluate CRL publication frequency, OCSP responder availability, and the CA's track record during mass-revocation events.
Trust store breadth is often overlooked. Not all CAs have equal coverage across operating systems, browsers, mobile platforms, and IoT device firmware. A CA that's trusted in Chrome and Firefox but missing from an embedded device's trust store is useless for that deployment.
CT log submission practices are worth verifying. All public CAs must submit to CT logs, but the speed and reliability of submission varies. Slower CT submission means longer delays before your CT monitoring can verify legitimate issuance.
The Automation Prerequisite
Multi-CA without automation is not multi-CA. It's two vendor relationships and a hope that someone remembers to switch when things go wrong.
The automation layer for multi-CA needs four capabilities. First, CA abstraction — your certificate request workflow should be CA-agnostic, with the CA selection happening at the policy layer, not in application code. Second, policy routing — rules that determine which CA handles which request based on certificate type, domain, environment, compliance requirements, or CA availability. Third, failover logic — automated detection of CA unavailability and transparent rerouting to the secondary CA. Fourth, consolidated observability — a single view of all certificates regardless of issuing CA, with unified alerting on expiry, issuance failures, and policy violations.
This is where the certificate management conversation shifts from tool to platform. Individual CA integrations are tools. The routing, policy, and observability layer that sits above them is a platform. And building that platform — or choosing one that does it well — is the strategic decision.
ACME protocol is the lingua franca that makes multi-CA feasible. Because ACME standardises the certificate issuance workflow, an ACME client can theoretically work with any ACME-compliant CA. In practice, there are CA-specific differences in challenge types supported, validation timing, rate limits, and error handling. A multi-CA ACME architecture needs to account for these differences in its routing logic.
For organisations already running ACME automation for a single CA, extending to multi-CA is an incremental step. For organisations still doing manual certificate management, the 47-day validity timeline means you need automation first, and multi-CA second. Don't try to solve both simultaneously.
Failover vs. Active-Active: Choosing Your Model
The decision between failover and active-active depends on three variables: certificate estate size, renewal velocity, and organisational risk tolerance.
Failover is appropriate for organisations with fewer than 5,000 certificates, moderate renewal frequency, and a defined primary CA relationship they're satisfied with. The key discipline is regular failover testing — at minimum quarterly, issuing real certificates through the secondary CA and validating the full lifecycle.
Active-active is appropriate for organisations with large certificate estates (10,000+), high renewal velocity, or exposure to regulated industries where CA-specific compliance requirements vary across certificate types. Active-active is also the natural model for organisations that have genuinely different CA needs for different parts of their infrastructure — for example, Let's Encrypt for automated web-facing DV certificates, DigiCert for OV/EV corporate certificates, and a private CA for internal service mesh.
The cost of active-active is operational complexity. Two CA relationships to maintain, two sets of documentation and runbooks, and policy routing logic that needs to be correct under all conditions. The benefit is resilience that's always warm — not cold failover that may not work when you need it.
For most enterprises, the practical starting point is use-case routing: map your certificate types to the CAs best suited for each, automate issuance through ACME, and ensure you have a tested failover path for each CA. As your automation matures and your certificate estate grows, you can evolve toward active-active for the certificate types that justify it.
What the Next CA Distrust Will Look Like
The Entrust and Symantec distrusts weren't anomalies. The CA/Browser Forum's compliance requirements are tightening, browser root programs are becoming more willing to enforce consequences, and the bar for CA trustworthiness is rising. It is entirely plausible that another publicly trusted CA will face distrust action within the next few years.
The organisations that survive the next distrust event without disruption will be those with multi-CA architecture already in place, ACME automation that can switch CAs without manual intervention, certificate observability that identifies affected certificates within hours, and a tested migration playbook — not one written during the crisis.
Your certificate strategy should assume this event will happen. The question is whether you've prepared for it or whether you'll be writing the playbook at 2am on a Saturday.
Sector context: Financial services M&A and payment-system migration, multi-entity CA design, manufacturing acquisitions & OT PKI.
← Back to Certificate Strategy: The Framework Most Organisations Skip
External References
- Google Chrome Entrust Certificate Distrust (June 2024) — security.googleblog.com
- Entrust Response to Chrome Distrust — entrust.com
- Apple Entrust Distrust (November 2024) — Apple Security Updates
- Mozilla Entrust Distrust (November 2024) — Mozilla Security Blog
- CA/Browser Forum Ballot SC-081v3: 47-Day Certificate Validity — cabforum.org
- Symantec CA Distrust (2018) — Google Security Blog
- AppViewX: 20%+ of Fortune 1000 Using Entrust — appviewx.com