Industry

The CA Consolidation Problem: What Happens When Let's Encrypt, Google Trust Services, and DigiCert Run 90% of the Public Web

May 24, 202612 min readCertPulse Engineering

In 2015, picking a certificate authority meant comparing roughly twenty real options: Comodo, Symantec, GeoTrust, Thawte, RapidSSL, GoDaddy, Entrust, GlobalSign, DigiCert, StartCom, WoSign, plus the cheap resellers stacked on top. By early 2026, three CAs issue approximately 90% of all publicly-trusted certificates on the web. CA market consolidation is the most consequential PKI shift of the decade, and almost nobody is talking about what happens when one of those three CAs has a bad afternoon.

This is not a doom piece. Let's Encrypt has been a net positive for the open web by any honest measure. But "the thing is good" and "the thing is now load-bearing for the entire internet" are different sentences, and we should probably say both out loud.

The Numbers Nobody Wants to Cite Out Loud

Three CAs issue ~90% of new publicly-trusted certificates in Q1 2026. According to Certificate Transparency log aggregates, the current issuance share breaks down as:

  • Let's Encrypt: ~55% of all publicly-trusted certificates
  • Google Trust Services: 15%+ and still accelerating
  • DigiCert, Sectigo, GlobalSign: split most of what remains
  • Everyone else: rounding error

The slope matters more than the snapshot. Let's Encrypt issuance share over time:

  • 2018: ~28% of new issuance
  • 2021: ~45%
  • 2026: 55% and climbing, because every new ACME-native platform defaults to it

Google Trust Services was effectively zero for non-Google domains until 2022; it is now larger than Sectigo. Meanwhile the long tail of regional CAs has flattened — not because they did anything wrong, but because no customer wants to maintain a renewal pipeline for a CA that issues 0.1% of the public web.

Historical concentration benchmarks:

  • 2015: dozens of CAs with meaningful market share, no single CA above ~20%
  • 2020: Let's Encrypt clears 50% of new issuance for the first time
  • 2026: top three CAs account for ~90% of new public certs
  • Active root certificates in major root stores: still ~150, but most are dormant or constrained

Most of those ~150 roots in the Mozilla root store are technically trusted but issue almost nothing. The illusion of CA diversity is mostly a root-store ledger, not real market structure.

How We Got Here: Free Certs, Browser Distrust Events, and the ACME Effect

CA market consolidation is not market failure. It is the predictable outcome of browser root programs raising the operational bar past what mid-sized CAs could clear, plus ACME making free certs operationally identical to paid ones.

Walk the timeline:

  • 2011: DigiNotar collapses after compromise and removal from root stores
  • 2016-2017: WoSign and StartCom collapse after mis-issuance and backdated-cert scandals
  • 2016: ACME ships; certbot matures, marginal cost of DV certs drops to zero
  • 2017-2018: Chrome, Mozilla, and Apple coordinate the Symantec distrust, wiping out ~30% of the existing certificate market in one browser action
  • 2023: CAs without mature ACME endpoints are effectively out of the new-issuance race
  • 2026: 47-day certificate lifetime mandate ratified

DigiCert acquired the residual Symantec business, but a huge chunk of customers migrated to Let's Encrypt during the forced reissuance window because they were already on the renewal treadmill and ACME was right there. CNNIC, TÜRKTRUST, Procert — every few years a CA gets caught doing something bad and exits the root store. Each distrust event compressed the field, and the surviving CAs absorbed the customers.

The 47-day mandate finished the job. There is no manual-renewal business at 47 days, only automation.

The takeaway: this consolidation was browsers picking winners by setting policy, not customers picking winners by buying. Browser root programs quietly became the de facto regulators of the public CA ecosystem, and Let's Encrypt happens to be exactly what their policies optimize for.

The Single-Point-of-Failure Math

If Let's Encrypt's issuance API goes down for four hours, roughly 40-50% of all new certificate issuance and renewal worldwide stops. This is not hypothetical. The September 2021 DST Root CA X3 expiry was the preview, and most teams handled it badly.

What actually breaks in a real Let's Encrypt outage:

Component Behavior During LE Outage
ACME clients pointed at LE Stall. Most certbot/acme.sh configs have zero fallback logic.
Renewals with 30+ days remaining Fine. Plenty of buffer.
47-day certs at the 7-day mark Sweating.
CDN-managed certs (Cloudflare, Fastly) Self-heal. CDN owns issuance logic and most use multiple upstream CAs.
Self-managed Kubernetes with cert-manager default LE issuer Do not self-heal. Pod retries, gets same error, retries again. Someone gets paged at 3am.

The 2021 DST Root CA X3 expiry was different in mechanism — a root cert expiring, not an API outage — but the blast radius was similar. Older Android devices, OpenSSL 1.0.2, anything that could not parse the cross-sign chain logic broke. The internet's collective response was "we'll handle the next one better," and then we mostly did not.

The actionable bit: check whether your ACME client retries forever on the same CA or has a configured fallback. If you are running cert-manager with a single ClusterIssuer, you do not have a multi-CA strategy. You have a wish.

Pricing Pressure: The Bottom Fell Out, Then What?

DigiCert, Sectigo, and Entrust in 2026 do not sell certificates. They sell certificate lifecycle platforms. Industry data indicates the enterprise PKI platform market is now larger in dollar terms than the old paid-cert business ever was.

What enterprise CAs actually sell in 2026:

  • Certificate lifecycle management (CertCentral, Trust Lifecycle Manager)
  • Private CA infrastructure
  • IoT device identity
  • Post-quantum migration tooling
  • HSM integrations
  • SCEP/EST endpoints for device fleets
  • SOC 2 evidence packages and compliance attestations Let's Encrypt explicitly refuses to provide

A DV cert from DigiCert costs essentially nothing as a line item — the value is in the surrounding platform.

The use case Let's Encrypt cannot serve: a bank with 40,000 internal certificates, six compliance regimes, and a board that wants signed attestations is not migrating to Let's Encrypt. It is paying DigiCert, Entrust, or Sectigo for the audit trail and managed PKI. The certificate is the receipt; the platform is the product.

This is also why "DigiCert is dying" takes from the 2018-2020 era aged badly. The DV market did die. The enterprise PKI platform market grew to replace it.

The Google Trust Services Question

Google Trust Services started issuing free public certificates for non-Google domains in 2022, and the strategic picture is now uncomfortable. Google's vertical integration spans every layer of the public TLS stack:

  • Chrome: ~76% global browser share (including Edge and other Chromium derivatives)
  • Root store policy: sets the rules that determine which CAs survive
  • CT log infrastructure: runs the logs the policy depends on
  • Google Trust Services: operates a free public CA competing directly with Let's Encrypt

Chrome's root program mandates 47-day lifetimes, CT logging, and a long list of operational requirements that effectively force CAs to be either huge or nonexistent. GTS clears every bar trivially because it is a Google product subject to Google's own engineering requirements. Smaller CAs spend disproportionate engineering time meeting Chrome's evolving policies.

To be clear: GTS has been a well-run CA. No mis-issuance incidents, clean CT log behavior, properly-staffed incident response. The conflict of interest is structural, not behavioral. When the entity setting the policy is also issuing the cert and operating the browser that enforces the policy, "trust us, we won't abuse it" is the only available defense, and the only check is "well, Mozilla still has a vote." That is a thin check.

If you are an engineer making CA choices in 2026, GTS is technically a fine option. Strategically, every cert you issue from GTS makes the consolidation problem worse. That tension does not have a clean answer.

What a Real Multi-CA Strategy Looks Like in 2026

A real multi-CA strategy has four ingredients: an ACME client configured with primary and fallback CAs, CAA records that explicitly allow both, monitoring that fires when the fallback gets used, and at least one rehearsal of the failover path per quarter. Most teams have the first ingredient and none of the others.

Concrete patterns by tool:

  • acme.sh: supports per-domain CA selection. Configure --server letsencrypt as primary and use a wrapper script to flip to --server google on failure. Ugly but works.
  • lego: point at any ACME-compliant endpoint. Run two parallel renewal jobs, one per CA. Load balancer takes whichever cert is fresher.
  • cert-manager: supports multiple ClusterIssuers, but you write the failover logic yourself. No built-in "try this one, then that one" primitive.
  • CAA records: list both CAs. Example: example.com. CAA 0 issue "letsencrypt.org" followed by example.com. CAA 0 issue "pki.goog". Without this, your fallback CA cannot issue even if configured correctly.

The honest take: for 90% of teams, single-CA on Let's Encrypt is the correct answer. Multi-CA adds operational complexity (two renewal pipelines, two sets of rate limits, two monitoring paths) for a failure mode that hits maybe once every few years.

Teams that genuinely need multi-CA:

  • Anyone whose revenue stops when TLS stops (fintech, exchanges, payment processors)
  • Anyone running infrastructure that cannot tolerate a 4-hour issuance gap (compliance-regulated SaaS)
  • Large platforms where the blast radius of a single CA outage is reputationally unacceptable

For everyone else, the better investment is catching the renewal-deployment gap and building monitoring that detects the failure modes that actually happen, not adding a second CA you will forget about until the audit.

What Breaks If This Continues

Three concrete failure scenarios worth taking seriously, ranked by probability and blast radius:

Scenario one: top-3 CA gets distrusted. Probability over 5 years: 5-10%. A Symantec-style mis-issuance audit finding against Let's Encrypt, GTS, or DigiCert would force a coordinated browser response that takes 20-50% of the web offline during the migration window. The 2017-2018 Symantec migration took 18 months with a much smaller incumbent. Doing this to LE today would be operationally apocalyptic.

Scenario two: regulatory pressure forces unwanted CA trust. Probability of meaningful disruption: high, timeline 2026-2028. The EU eIDAS QWAC mandate is the underrated PKI story of the decade. eIDAS 2.0 requires browsers to trust Qualified Web Authentication Certificates issued by EU-designated Trust Service Providers, regardless of whether browser vendors think those CAs meet their security bar. Mozilla, Apple, and Google have been pushing back for years. If the EU wins this fight as written, browsers lose the unilateral root-store-policy power that drove all the consolidation described above.

Scenario three: state-actor compromise of a top-3 CA intermediate. Lower probability, catastrophic impact. Would force mass distrust of a major issuer and reissuance of hundreds of millions of certs in a compressed window. Modern PKI infrastructure is not designed to reissue at that rate, and the rate-limit math does not work even if it were.

CA market consolidation increases the impact of all three scenarios. Same failure, bigger blast radius.

The CertPulse View: What We See Across 1,400+ Monitored Certs

CertPulse monitors 1,400+ TLS certificates across SMB and mid-market environments. Across that fleet, Let's Encrypt accounts for ~68% of monitored certs, versus 55% in global CT log averages. That gap is sample bias: the SMB/mid-market segment is overwhelmingly ACME-on-LE because it is free and it works.

What is striking across 1,400+ monitored certificates: near-zero multi-CA deployments outside of fintech and a small handful of SaaS platforms. Most teams that claim multi-CA in conversations are running a single CA with a "we could switch if we had to" plan that has never been tested. The gap between best-practice advice and operational reality is wider than the certificate industry likes to admit.

The honest read from operating a monitoring product: CA market consolidation is real, accelerating, and the mid-market is the most exposed segment because it has neither the scale to negotiate enterprise contracts with paid CAs nor the engineering capacity to maintain a real multi-CA failover. The right answer for most of these teams is not multi-CA. It is better monitoring of the single CA they depend on, faster detection when renewals fail, and a documented manual fallback path for the rare outage event.

FAQ

Q: Is using only Let's Encrypt risky in 2026? For most teams, no. Let's Encrypt has high uptime, multiple intermediates, and a mature operations team. The risk concentrates in scenarios where a multi-hour outage during your renewal window causes real damage. For a personal blog or an internal tool, single-CA on LE is fine. For a payment processor, it is not.

Q: Should I switch to Google Trust Services? Technically GTS works fine. Strategically, using GTS makes the consolidation problem worse and hands more leverage to a vendor that already controls the browser and the root program. If you care about that, prefer Let's Encrypt or pay a non-Google CA. If you do not, GTS is operationally indistinguishable.

Q: What is the simplest multi-CA setup? Two ACME clients, two issuers (Let's Encrypt primary, GTS or ZeroSSL fallback), CAA records that allow both, and a cron job that periodically forces a renewal through the fallback path so you find out when it is broken before you need it.

Q: Will the 47-day mandate accelerate consolidation? Yes. The 47-day lifetime is impossible without ACME automation, and ACME at scale strongly favors CAs with mature free endpoints. Smaller CAs without competitive ACME offerings will continue losing share through 2029.

Q: What is eIDAS QWAC and why does it matter? eIDAS QWAC (Qualified Web Authentication Certificates) is an EU regulatory framework that would require browsers to trust certain EU-designated CAs. Mozilla and others argue this undermines the security bar root programs enforce. The outcome of this regulatory fight will reshape the global CA market more than any technical change in the next five years.

This is why we built CertPulse

CertPulse connects to your AWS, Azure, and GCP accounts, enumerates every certificate, monitors your external endpoints, and watches Certificate Transparency logs. One dashboard for every cert. Alerts when auto-renewal fails. Alerts when certs approach expiry. Alerts when someone issues a cert for your domain that you didn't request.

If you're looking for complete certificate visibility without maintaining scripts, we can get you there in about 5 minutes.

The CA Consolidation Problem: What Happens When Let's Encrypt, Google Trust Services, and DigiCert Run 90% of the Public Web | CertPulse