Trusted Everywhere, Impact Everywhere

One of the private keys behind eight eMudhra intermediate CA certificates was the integer 4. Several other keys in the same set were nearly as easy to recover. Keys capable of supporting trusted TLS issuance made it through key generation, certification, auditing, and root program review before an outside researcher noticed, and the previous article examined how that happened.

This article asks why a failure at an Indian CA became an incident response problem for relying parties around the world that had never chosen to use eMudhra.

The answer lies in how the WebPKI allocates trust. A CA admitted without constraints to a browser or operating system root store can certify names far beyond the customers, country, language, or regulatory regime it actually serves. Root stores differ, some CAs carry name constraints, and some applications maintain their own trust stores, so not every client trusts every CA. Wherever that authority is accepted, though, the relying party inherits the security consequences. The web has often treated a legitimate preference for local control as if it required global signing authority, and those are different things.

What does the web actually need?

If the goal is that every website can authenticate itself and offer encrypted connections to anyone with a modern browser, the web does not need a publicly trusted CA in every jurisdiction. A much smaller set of operators than the number admitted to the global root stores could meet that need. Removing the long tail would still be disruptive, because operators would have to reissue certificates, migrate systems, and unwind dependencies. The question here is technical necessity, which is separate from whether fewer issuers would be desirable.

A Swedish company may want a CA that serves it in Swedish. A German ministry may prefer a provider that understands German regulation, contracting, and business practice. Governments may want domestic oversight, local availability, and independence from foreign institutions. These are legitimate benefits, and they are preferences and policy objectives layered on top of the web's core authentication requirement. A local language, a local vetting team, or a domestic contracting relationship can also be offered by a registration authority or service provider that obtains certificates from an issuing hierarchy that is already trusted. That arrangement may not satisfy a government that wants fully independent national cryptographic infrastructure, but it separates what customers need locally from what relying parties everywhere must trust.

The WebPKI obscures this distinction because admission gives a local provider much more than local service. It gives that provider authority over the global web.

A handful of CAs issue most web certificates

The WebPKI Observatory builds an issuance view from Certificate Transparency and CA ownership records. In its October 22, 2026 snapshot, the three largest organizations accounted for 71.4% of unexpired publicly trusted certificates, the top five for 88.8%, and all remaining CAs together for 11.2%.

These figures are counts of unexpired certificates in circulation. They do not count customers, domains, HTTPS connections, or daily issuance, and one customer may hold many certificates while a heavily used site holds few. They describe each CA's deployment footprint and, roughly, how much of the operator side depends on it.

Geography is more lopsided still. Of the 84 CA organizations the Observatory classifies by location, the 15 in the United States make up 17.9% of organizations and hold 92.76% of certificates. The 44 European organizations make up 52.4% and hold 7.15%. The 25 organizations in all other regions hold 0.09%.

The Observatory also identifies 30 government-operated or state-owned CA organizations in the root stores, which together account for 0.09% of unexpired certificates. Their presence may serve national policy objectives, and their safety has to be judged case by case, but the rationale for their broad trust cannot rest on the share of the certificate market they serve.

The Observatory counts 88 organizations trusted by at least one major root program, while the geographic figures use only the 84 it classifies by location. The 92.76% and 7.15% figures come from that geographic series and are computed separately from the top-five ranking.

This is the distinction between what the web needs and what the governance system permits. Many organizations participate in global trust, and very few of them carry nearly all of the actual certificate footprint.

Certificate counts and browser usage tell different stories

Matthew McPherrin's cert-count dataset offers a second measure of dependence. It aggregates Mozilla's cert.validation_success_by_ca_2 telemetry, which counts successful server certificate validations attributed to each CA, for the Firefox 157 and 158 release channel builds, as retrieved from Mozilla's GLAM service on October 22, 2026. The issuance data shows which providers supply deployed certificates, and the telemetry shows which CAs participating Firefox clients actually encounter.

The two columns rank the same CAs differently. Google Trust Services leads Firefox validations at 28.53% while holding 21.0% of certificates, and ISRG leads certificates at 32.6% while carrying 26.54% of validations. GoDaddy shows the widest gap, with 10.6% of unexpired certificates but only 1.44% of Firefox validations. Amazon Trust Services, which sits inside the remaining certificate share, accounts for 10.93% of validations on its own. A provider can serve millions of lightly visited names while another protects a smaller population of sites people load many times a day, so the two measures diverge for ordinary reasons. The columns come from different measurement windows and should be compared as rankings of dependence rather than as a synchronized time series.

The telemetry counts successful validations rather than distinct users, websites, or visits, and it samples participating Firefox installations rather than the browser population as a whole. StatCounter's September 2026 measurements put Firefox at 2.80% of worldwide browser share across devices, or 6.11% on desktop, and Firefox users need not browse the way Chrome or Safari users do. Browser share shows how narrow the sample is, and multiplying Firefox's CA percentages by it cannot reveal the CA mix in other browsers.

What happens when a CA certifies the wrong website?

Both measures describe CAs that websites chose or that Firefox users encountered. Neither says what happens when a CA certifies a website it has no right to certify, and answering that requires looking at what a browser actually checks.

When you visit a website over HTTPS, the site presents a certificate naming the domain and a public key. Your browser checks that the certificate chains to a CA in its root store and that the domain name and other requirements match. The browser does not normally require that the website chose that particular CA, and it accepts a valid chain to any CA authorized for that name in its root store. This is what makes competition and interoperability possible, since a site can change providers without asking anyone to update a browser.

It also means that, unless a CA's authority is limited by name constraints or other validation controls, a CA serving a tiny local market can make a certificate claim about an unrelated website anywhere in the world. The victim does not have to be that CA's customer. Successful impersonation still depends on the attacker's ability to present the certificate and on client protections such as Certificate Transparency, revocation, and blocklists, but the CA's share of legitimate certificates places no bound on the set of names it might wrongly authenticate.

A CA responsible for 0.001% of deployed certificates does not have 0.001% of the ability to issue a certificate for a major website. Issuance share describes commercial and operational dependence, and Firefox validations describe observed browser exposure. Neither describes how broadly a CA is allowed to sign, which is what determines the cost a CA imposes on the rest of the web.

When a small CA fails, the rest of the world pays

The cost of adding another broadly trusted issuer goes well beyond that issuer's audits or the number of certificates it issues. Every relying party that accepts it takes on that issuer's key management, validation behavior, incident response, ownership changes, and eventual failure.

On October 17, 2026, a researcher reported that the private keys for eight eMudhra subordinate CA certificates had been generated with insufficient randomness and could be recovered. Chrome's account says its team corroborated the report and blocked the affected intermediate public keys through CRLSet within roughly 100 minutes, and Mozilla distributed a OneCRL block. Cloudflare describes remediation spanning clients, proxies, services, trust stores, containers, and applications that do not inherit browser updates automatically.

Chrome's report also says that no TLS certificates chaining to the six affected intermediates within the scope of its CT check had been logged before the block, so CT-enforcing clients could not have accepted unlogged forged certificates through that publicly trusted path. eMudhra's incident statement says none of the eight intermediates had issued end-entity certificates. That statement describes its legitimate issuance records, and anyone able to recover a signing key could have produced certificates outside them. The remaining risk sat with clients that trusted the keys but did not enforce CT, receive timely blocklist updates, or inherit browser protections.

Chrome and Mozilla acted decisively, and the incident still required coordinated remediation well beyond browsers, because public trust extends into applications and devices with different validation logic and update cadences. eMudhra Technologies accounted for 0.025% of the Firefox validations in the telemetry above. It did not have to matter to those clients' legitimate traffic in order to matter to their security.

The benefit of local issuance can be concentrated in one country or customer segment, while the authority conferred by broad trust, and the work of cleaning up its failures, are spread across everyone.

Where the WebPKI’s 16 recorded trust actions occurred

The Observatory's historical list records 16 trust actions against CAs from 2011 through 2024. The Observatory labels them distrust events, but they range from complete root removal to narrower restrictions. ANSSI's 2013 incident, for example, ended with the offending intermediate blocked and the root's scope limited. By jurisdiction of the CA operator, five involved European CAs (31.25%), four involved Asian CAs (25%), three involved U.S. CAs (18.75%), two involved CAs in Türkiye (12.5%), and two involved Latin American or Caribbean CAs (12.5%). In total, 13 of 16, or 81.25%, involved CAs outside the United States. The chart treats Türkiye as its own transcontinental category and places StartCom under its historical Israeli operating identity, with its later Chinese ownership covered in the methodology notes.

These are descriptive counts of trust actions. They are neither per-CA failure rates nor a standardized record of root removals, and the cases span different eras, root programs, ownership structures, and kinds of action. Estimating comparative risk would require historical denominators covering how many CAs operated in each region each year, how much trust and issuance each held, and consistent inclusion criteria. The counts show where trust actions have arisen and say nothing about any national characteristic of European or non-U.S. CAs.

A narrower and more serious category consists of unauthorized certificates capable of impersonating domains that were actually issued. That category is distinct both from a CA's mere ability to issue such certificates and from proof that traffic was intercepted. Several cases on the list have direct evidence of it.

• DigiNotar (Netherlands, 2011). A fraudulent *.google.com certificate was observed being presented to users in Iran, as documented in the independent Fox-IT investigation.
• TÜRKTRUST (Türkiye, discovered 2012). A mistakenly issued subordinate CA was used to produce a fraudulent *.google.com certificate. This was the 2012 to 2013 misissuance, which predates the Observatory's 2018 entry for TÜRKTRUST. Google's incident report and Microsoft's advisory document it.
• ANSSI (France, 2013). An unauthorized subordinate certificate was installed in a TLS interception appliance and used for domains the holder did not control, according to Mozilla's advisory and Google's disclosure.
• India CCA / NIC (India, 2014). NIC issued unauthorized TLS certificates covering Google and Yahoo domains. Google noted that the Indian government roots were then trusted through the Microsoft root store rather than by every browser or platform, and it constrained its own trust in response. Google's investigation and Microsoft's advisory give the details.
• CNNIC / MCS Holdings (China, 2015). An intermediate issued under CNNIC produced unauthorized certificates for Google domains, and Google documented the incident and its immediate block.

The list is illustrative rather than exhaustive, and interception was not demonstrated in every case. Counting leaf misissuance, trust restrictions, and CA removals in a single number would combine different events, and an unauthorized subordinate CA certificate belongs in this category only when later leaf issuance is documented.

The geographic chart shows how trust actions are distributed, and the incident reports show how the failures happen. Both point to the same mechanism. A CA with little legitimate traffic can produce an authentication claim that is accepted far outside the market it serves, and a single unauthorized certificate is enough to demonstrate it.

A country can control local identity without controlling global TLS trust

The European Union’s eIDAS framework puts this tension into law. Articles 45 and 45a of Regulation (EU) 2024/1183 require browsers to recognize qualified certificates for website authentication, display specified identity attributes, and observe procedural requirements when taking certain precautionary security measures. Article 45(1b) also limits additional mandatory requirements. Member states determine which providers are qualified under the European framework. The accompanying recitals express an intention to preserve browsers’ freedom to secure connections, but recitals guide interpretation; they do not cancel the operative obligations. The unresolved tension is between independent browser security judgments and the legal requirements attached to recognizing a government-approved trust service.

These requirements arise within the EU’s jurisdiction, but their practical effects are difficult to confine there. A website generally presents the same certificate chain to visitors around the world. If that chain is accepted in one region and rejected in another, the site can fail for visitors outside the first region. Maintaining region-specific chains or browser trust policies across the global web would require complex changes to certificate automation, deployment, location handling, caching, and compatibility. That is not a realistic general answer to conflicting trust requirements. Consequently, European decisions about browser obligations can affect relying parties far beyond Europe, even though the EU does not directly regulate every user or application worldwide.

The history makes this concern concrete. European CAs account for five of the sixteen historical trust interventions in the Observatory’s list, more than any other region in that dataset. Those entries include ANSSI, where browsers independently restricted a CA’s scope after unauthorized issuance. The historical count is not a regional failure rate, but it demonstrates why browsers need to retain the ability to intervene on technical security grounds. Article 45a places procedures and conditions around certain precautionary measures involving qualified certificates. That creates a pointed governance question: when the security interests of global relying parties and the qualification decisions of a regional regulator conflict, who gets to decide what a browser must trust?

The WebPKI has already used geographic scope in incident response. After the 2013 ANSSI misissuance, Chrome announced that it would limit the ANSSI CA to .fr and a defined set of French territorial top-level domains, and Mozilla documented the same restriction. The offending intermediate was blocked, and the CA's wider trust was restricted rather than removed. After the 2014 India CCA / NIC incident, Chrome announced a similar restriction covering specified Indian government, academic, banking, and technology domains. In neither case did the browsers have to conclude that every domestic certificate was worthless, and both responses reduced where the trust could be exercised.

These were restrictions enforced by browser root programs, and other platforms did not necessarily enforce equivalent X.509 name constraints. Country-code scopes also fit the real DNS poorly, since German and Swedish organizations use .com and a country-code suffix maps cleanly to neither citizenship, ownership, nor regulatory jurisdiction. Even so, the ANSSI and India CCA cases show that global trust scope is a policy and implementation choice, and a functioning domestic CA does not depend on it.

The European framework bears directly on this kind of response, and the irony is hard to miss. Europe accounts for more of the sixteen trust actions than any other region, including ANSSI, the case that gave browsers their clearest precedent for scoped trust. The ANSSI restriction was a decision Chrome and Mozilla made on their own and carried out quickly. For QWACs and the qualified providers that issue them, Article 45a now attaches a prescribed procedure, including notification of the Commission and the relevant supervisory body, to precautionary measures of that kind. Europe leads the documented CA trust-intervention count in this dataset, while also having written the rules that most directly constrain browsers' ability to respond to failures involving qualified providers.

A local-language issuance service, a domestic registration authority, or a regulated provider of verified legal identity can meet much of the practical customer demand without adding another unconstrained global root. A government may want something stronger, namely full cryptographic independence from foreign CA operators. That is a genuine sovereignty objective with real benefits and trade-offs, and it should be debated on those terms rather than treated as a free property of a shared global root store.

Post-quantum migration gives us a chance to change the trust model

The classical public WebPKI is not the endpoint. Quantum computers threaten the signature algorithms its authentication model relies on, and large post-quantum signatures create practical scaling problems for classical X.509 certificate chains. As explored in The Post-Quantum WebPKI and A Deep Dive on the Classical WebPKI, the transition involves much more than swapping one signature algorithm for another.

Chrome's post-quantum WebPKI work includes Merkle Tree Certificates and a proposed separate quantum-resistant root program. The details are still evolving, and classical and post-quantum systems will coexist through the migration. The cryptographic pressure behind the migration has nothing to do with sovereignty, but it creates a rare moment when root program admission and trust scope can be reconsidered deliberately. A Merkle proof cannot tell a browser whether a legal or domain control assertion was authorized, and nothing about quantum resistance requires granting every admitted issuer authority over every domain. The longer technical analysis covers the MTC machinery, and the decision at issue here is a governance one.

Who should bear the security cost of sovereign CAs?

Limiting the scope of trust does not require reducing the number of CAs. Concentrating issuance in a few very large providers would create its own points of operational failure, commercial dependency, censorship pressure, and geopolitical leverage, and a CA's nationality says nothing about the competence of its staff. Scoping trust leaves room for many issuers while limiting what each one can sign.

The practical choices are narrower. Sovereign or locally focused CAs can be constrained to country-code top-level domains and to specifically enumerated government or other approved domains, including names under generic top-level domains where a meaningful scope can be defined. Unconstrained global authority should be reserved for CAs that meet a substantially higher bar for technical quality, operational discipline, incident response, and demonstrated value to the web as a whole. That bar is hard to quantify fairly, but the difficulty of drawing it does not justify making worldwide authority the default.

This is a cost accounting problem as much as a technical one. The provider, country, or customer base that receives the local benefit does not bear all of the security cost. When a broadly trusted CA fails, browsers, independent software vendors, enterprises, service operators, and relying parties elsewhere absorb the assessment and remediation burden, and that burden bears no relation to legitimate issuance or usage share.

One way to distribute that cost would be to require globally trusted CAs to post a bond or carry comparable financial assurance. That would at least make admission carry a price tied to the harm an issuer can impose. But it could also turn access to global trust into a test of capitalization rather than operational quality. The Internet Security Research Group, which operates Let's Encrypt, is a nonprofit and one of the web's best-run CAs; a large bond could exclude or burden it without proving that a wealthier operator is safer. Any financial mechanism would therefore have to avoid treating the ability to pay as evidence of competence.

The tax is paid continuously, not only after an incident. Every additional broadly trusted issuer adds another organization whose key management, validation controls, software, personnel, governance, and incident response everyone who accepts it must depend on, even if those relying parties never intentionally transact with that CA. A compromise makes that dependency visible, but the dependency existed long before the compromise was discovered.

A Swedish company can reasonably want a Swedish-language CA. A German ministry can reasonably want a German trust provider. An Indian company can reasonably compete for global customers. We may choose to support all of those aims for the sake of competition, resilience, and sovereignty, but technical necessity, customer preference, and national policy are three different arguments, and only technical necessity answers what the web requires in order to function.

We are about to migrate one of the internet's oldest shared trust systems to post-quantum cryptography. Before we do, it is worth asking whether to carry forward a design in which a CA with little legitimate global market share can still authenticate names everywhere. If the local benefit is real, why should the global scope be automatic?

A CA that is trusted everywhere has impact everywhere, and that is the sovereignty tax.

---

Data and methodology notes

• Observatory snapshot. WebPKI Observatory landing page and JSON snapshot viewed October 22, 2026. Market-share figures are proportions of unexpired certificates, not counts of distinct site operators. The Observatory reports 88 CA organizations in at least one major root program and 84 geographically classified organizations, and the geographic comparison uses the 84. Top-five shares are rounded to one decimal place.
• Jurisdiction method. The Observatory's 16 historical trust actions are assigned to the CA operator's country, not to the location of affected websites or users. Europe (5) covers DigiNotar (Netherlands), ANSSI and Certinomis (France), Camerfirma (Spain), and e-commerce monitoring/GLOBALTRUST (Austria). Türkiye (2) covers TÜRKTRUST and e-Tugra. Asia (4) covers India CCA/NIC (India), CNNIC and WoSign (China), and StartCom (historically Israel, later Chinese-controlled). Latin America and the Caribbean (2) covers PROCERT (Venezuela) and TrustCor (Panama). The United States (3) covers Symantec, Visa, and Entrust. The list mixes eras and kinds of trust action, including ANSSI's scoped restriction, so 13 of 16 is descriptive and is not a risk estimate. Mozilla's PROCERT root inclusion record identifies its Venezuelan operating identity, TrustCor identifies its Panamanian registration, and Mozilla's StartCom ownership discussion documents its ownership history.
• Firefox method. Shares are computed from CA.csv in the mcpherrinm/cert-count repository as of its October 22, 2026 update, which sums Mozilla GLAM cert.validation_success_by_ca_2 histograms for Firefox 157 and 158 on the release channel and maps histogram bins to CA names using Firefox's KnownRootHashes.txt. The total is 178,009,832,890 successful validations. The telemetry reflects participating Firefox clients only, and its window differs from the Observatory snapshot.
• Legal timeline. Regulation (EU) 2024/1183 amended eIDAS. Articles 45 and 45a are discussed in their adopted form.
• Quantum timeline. MTC and Chrome's proposed quantum-resistant root program are an announced program and an active standards effort. Proposed policies and rollout dates are not presented as completed facts.

Primary and supporting sources. WebPKI Observatory · Observatory data snapshot · Mozilla CA telemetry metric · Firefox CA validation dataset · StatCounter browser share · Chrome eMudhra notice · Mozilla eMudhra notice · Cloudflare eMudhra notice · eMudhra incident statement · eIDAS amendment · Fox-IT DigiNotar report · Google TÜRKTRUST report · Google ANSSI response · Mozilla ANSSI advisory · Google India CCA response · Google CNNIC response · Chrome's MTC announcement · Classical WebPKI explainer · Post-Quantum WebPKI explainer