350 Roots, One Byte: What eMudhra Means for the Multi-CA Trust Model

The Architecture, Briefly

Every TLS client - browsers, SDKs, embedded devices - ships with a trust store: a list of certificate authority public keys that the client will accept as the start of a chain of trust. The Mozilla CA Certificate Program's current store contains about 150 roots. The Chrome Root Program ships about 100. Microsoft, Apple, Oracle Java, and various Linux distributions each curate their own but mostly converge.

Any CA in your trust store can issue a certificate for any domain. If LetsEncrypt vanished tomorrow, Sectigo could issue your TLS cert. If Sectigo vanished, DigiCert could. The system is designed so that no single CA failure takes down the web.

The flip side: any single CA compromise lets the attacker issue certificates that the entire trust-store ecosystem will accept. The compromise doesn't have to be malicious. It can be - as in the eMudhra case - a script bug.

This is the structural tension at the heart of the WebPKI. Redundancy against failure is also redundancy for compromise. You cannot have one without the other.

What eMudhra Actually Demonstrated

The specific incident:

• 8 intermediate CAs issued in April 2025 with single-byte private keys (nominally 384-bit ECC; actually about 2^3 bits of real entropy)
• Cross-signed by Sectigo's AAA Certificate Services root in May 2025
• Discovered via Certificate Transparency logs by an independent researcher in October 2026
• Blocked by Chrome, Firefox, and Safari within hours of the public report

The CA incident response - CCADB, Mozilla's forum, Chrome's root program, Apple's own blocklist - worked exactly as designed. The compromised intermediates were out of browser trust within one revision cycle. For browser users, the incident is over.

What this proves:

1. Certificate Transparency is a working detection mechanism. The researcher found this without eMudhra's cooperation, without Sectigo's cooperation, and without any insider access. The CT logs were sufficient.
2. The browser root programs can move quickly when the evidence is clear.
3. The browser-side revocation mechanisms (CRLSet, OneCRL, Apple's blocklist) actually work.

What this doesn't prove:

1. That the WebPKI's governance is proactively catching bad CAs.
2. That the issuing CA's own controls caught this.
3. That the non-browser ecosystem will catch up.

Point 1 and 2 are the governance critique the Hacker News commentary centered on. Point 3 is the operational critique the previous two posts in this series focused on. This post is about point 1 and 2.

The Diligence That Should Have Caught This

Six checkpoints existed between "the eMudhra script output a toy key" and "the intermediate was in CT logs":

1. The HSM output. The HSM generated a correct 384-bit scalar. A sanity check comparing the HSM's declared output to the script's final artefact would have caught the single-byte substitution. This is a defect at eMudhra.
2. The ceremony witness. A key-generation ceremony is supposed to produce artefacts that are inspected before release. Nobody looked at the private key material carefully enough to notice it was a byte. This is a defect at eMudhra.
3. The CSR self-check. The CSR is signed by the private key being certified. A verifier that computed the public key from the CSR's declared public key and compared against the CSR's signature would have passed - the single-byte scalar is still a valid P-384 scalar, it's just a laughably weak one. A deeper check - "is this key's scalar within the lowest 2^16 of the curve order" - would have failed. This check is cheap and nobody runs it. This is a defect in the industry.
4. Sectigo's cross-signing diligence. When you cross-sign a subordinate CA, you are putting your reputation behind that CA's operations. The specific technical check - "is the subject's public key on the correct curve, and does the claimed private key have at least some evidence of adequate entropy (e.g., the public point is not a small multiple of the generator)" - is cheap. Sectigo didn't run it. This is a defect at Sectigo.
5. The browser root programs' continuous monitoring. Mozilla, Google, Apple, and Microsoft all review new intermediates added to CCADB. The intermediates landed. The browser root programs did not catch this before the researcher did. This is a shared defect across root programs.
6. The CT log scanning. Multiple third-party CT log scanners exist. None of them, until the researcher looked, caught this. The specific scan - "for every new intermediate in CT logs, verify the public key is not a small multiple of the generator" - is a weekend project. Nobody did it. This is a defect in the broader security community.

Six checkpoints. All existed. None fired. The research community caught it eighteen months after issuance.

The Governance Response So Far

Mozilla's root-store distrust process is well-documented and has, in the past, resulted in CA removals (Symantec, DigiNotar, TurkTrust, Camerfirma). The eMudhra incident is almost certainly going to end with eMudhra's roots being distrusted by at least Mozilla and probably Chrome. The downstream effect is that every TLS certificate chained through those roots has to be reissued through a different CA.

What this does not fix:

• The structural issue that any CA in the trust store can issue for any domain.
• The non-browser clients that don't update when the browser trust store updates.
• The economic incentive that drives CAs to minimise ceremony costs and skip diligence checks.

What governance changes are being discussed:

• Mandatory third-party key-generation audits before cross-signing. The failure mode here was a bug in eMudhra's script that Sectigo's cross-signing audit should have caught. If audit standards required inspection of the artefacts, not just the process, the single-byte scalars would not have survived.
• Automated public-key health checks on CT ingestion. Any CA that issues a certificate whose public key is a small multiple of the generator should trigger an automatic alert at the browser root programs. This is a cheap check and the CT log operators are the natural place to run it.
• CAA record binding. Current CAA records are advisory; a non-compliant CA can issue in violation of CAA and the certificate still validates. Binding CAA checks (where the client-side TLS validation enforces CAA policy) would reduce the "any CA can issue for any domain" problem - at the cost of operational complexity and performance.
• Root count reduction. The maximalist proposal: cut the trust store from ~150 roots to ~30 roots operated by organisations with proven governance. This is politically fraught and would freeze out legitimate newer CAs, but it does bound the attack surface.

What CISOs Should Actually Do

If you are responsible for an organisation that depends on the WebPKI (every organisation that uses TLS, which is every organisation), the eMudhra incident is a prompt to answer four specific questions:

1. Which CAs are in our trust stores?

The answer is almost certainly "we don't know." The default system trust stores on Linux, Windows, macOS, and the various container base images diverge, and the trust stores pinned in network appliances, IoT devices, and compiled Go binaries diverge further. The inventory is the thing that makes you able to answer the "are we exposed?" question in minutes rather than days.

2. Which of our critical paths rely on CA-level trust vs. pin-level trust?

Any outbound call to a payment processor, OAuth provider, SaaS vendor, or internal service that depends on a specific hostname is a candidate for SPKI pinning. Pinning doesn't eliminate the dependency on the public PKI, but it does mean a different CA failure doesn't impact that path. Decide which paths matter. Pin them.

3. What's our revocation story?

If a CA you trust is compromised tomorrow, how long does it take for your systems to stop trusting it? The browser answer is "hours." The non-browser answer varies from "an OS update cycle" to "never." Make this explicit. Document the window. Shorten it where you can.

4. What's our story for the next decade's trust-store governance?

The CAs you depend on today will not all exist in 2036. The devices you shipped in 2019 are still in the field and will be until 2029 or later. The trust decisions you make now have 10-15 year half-lives. Build the trust-store update path for anything you ship. Document which CAs each product line depends on. Review the dependencies annually.

The Private PKI Case

The eMudhra incident is specifically a public PKI incident. For organisations running private PKI - internal CAs issuing certificates to internal systems - the direct exposure is smaller, but the architectural lesson is the same.

If your internal CA is compromised, how fast can you rotate? The TigerTrust answer is: dual-trust push → shadow issuance against the new CA → scheduled promote in a change window → retire the old CA when the last cert expires. For internal estates, this is a tractable 8-12 week migration. For public PKI, the equivalent migration is driven by the browser root programs on their own cadence.

The implication: an organisation with a well-run private PKI has more agility to respond to a compromised anchor than an organisation that depends only on public CAs. If you were going to invest in internal PKI anyway, the eMudhra incident is one more reason to do it sooner.

The Honest Conclusion

The multi-CA trust model is architecturally fragile. The industry has not solved this. The industry probably cannot solve this - the alternatives (DNS-based PKI, DANE, single-sovereign trust) have their own structural issues and have not displaced the CA model in twenty years of trying.

What the industry can do, and what the eMudhra incident reinforces, is:

1. Keep investing in Certificate Transparency and the detection it enables.
2. Keep investing in root program governance.
3. Reduce the response time between "compromise discovered" and "trust store updated" for the clients that currently take weeks to update.
4. Build the inventory, pinning, and short-lifetime discipline on the operator side so that any given CA compromise is survivable without a fire drill.

The eMudhra response demonstrated items 1 and 2 working. The items 3 and 4 agenda is the one operators still own.

Related Reading

• eMudhra, eight bytes of entropy, and what breaks - the incident analysis
• The non-browser trust store blind spot - the ecosystem below the browser
• Shadow issuance pattern for CA migrations - the architecture that makes private-PKI pivots fast
• Scott Helme: Eight Bits of Trust - the original write-up