eMudhra CA Keys: A Q-Day Rehearsal at the Scale of One CA

October 21, 2026 – Browser makers, operating system vendors and open-source maintainers have spent four days blocking eight intermediate certificates issued by eMudhra Limited, an India-based certificate authority, after a researcher showed on October 17 that their private keys could be computed from the public certificates. Each of the eight private keys was a number between 4 and 237.

Google’s Chrome blocked the six intermediates used for TLS, the protocol that secures HTTPS, 1 hour and 40 minutes after its root program received the report, and Mozilla blocked them in Firefox in under three hours. Apple’s platforms followed on October 19 and Microsoft’s on October 20, according to a disclosure site run by Mozilla cryptography engineer Dennis Jackson. Linux distributions, language runtimes and embedded devices were still being updated on October 21, a process Go cryptography maintainer Filippo Valsorda told Ars Technica would be “a massive cleanup job, bigger than Heartbleed.”

Certificate authorities, or CAs, use intermediate certificates to issue website certificates without putting their root keys online. Mozilla said the eMudhra keys “could allow attackers to issue fraudulent HTTPS certificates for websites they do not control.” The six TLS intermediates were issued by emSign Root TLS CA – G3. Microsoft’s root store includes that certificate as a root, while Apple, Google and Mozilla included eMudhra’s emSign ECC Root CA – G3, which cross-signed it, according to the disclosure site’s root list.

How the Keys Were Reported and Blocked

A researcher identified only as Wayne reported the problem to the four root programs and to eMudhra on October 17, according to security researcher Scott Helme. Wayne proved control of the keys by signing the message “We have a problem here – Wayne” with each of them, and the disclosure site published the signatures with commands to verify them.

Jackson wrote in Mozilla’s incident report that the eight keys “all used integers less than 256.” Helme published the values as 4, 56, 66, 115, 155, 156, 230 and 237. A correctly generated private key for NIST P-384, the elliptic curve eMudhra used, is a random number about 384 bits long, while the eMudhra keys were between 3 and 8 bits long.

An attacker recovers such a key by multiplying the curve’s base point by 1, 2, 3 and so on until the result matches the public key in the certificate. For the eMudhra keys, that search ends in at most 255 steps.

Chrome’s root program said it received the report at 18:05 UTC and blocked the six TLS intermediates at 19:45 UTC through CRLSets, the list Chrome uses to push certificate blocks to browsers without a software update. The block matched the keys themselves, so it also covered Sectigo’s cross-signed copies. Mozilla said it received the report at 20:06 UTC and completed a OneCRL update, its equivalent mechanism, at 22:59 UTC.

eMudhra revoked the eight certificates at 09:38 UTC on October 18, according to Mozilla’s incident report, and Sectigo, which had cross-signed all eight under its AAA Certificate Services root on May 14, 2025, revoked its cross-signed copies. Google said Android devices received an equivalent block through Google Play Services at about 22:00 UTC on October 19, and that most devices had it.

Chrome said it found no certificates chaining to the six TLS intermediates in Certificate Transparency logs, the public records that Chrome, Safari and desktop Firefox require for trusted certificates. As a result, no forged certificate from those intermediates could have been trusted by default in browsers that enforce the logs, Chrome said.

Mozilla wrote in its incident report that “the circumstances warrant the emergency removal of trust in emSign ECC Root CA – G3” and released NSS 3.131.1, the version of its certificate library that drops the root. Firefox 158.0.1 and the ESR releases 115.43.1 and 153.5.1 apply the block for users who had disabled the browser’s remote settings. Google said it had removed the same root from the Chrome Root Store, effective for devices on October 27. Chrome’s root program said the removal would ship in version 43 of the store.

eMudhra said about 30,000 certificates chaining to that root must move to its RSA root, emSign Root CA – G1, and that “about 97% came via ACME,” the protocol used to automate certificate issuance. eMudhra told Mozilla that only one of the eight, EM DV TLS CA – G3C, had been put into production, and that none of them had issued end-entity certificates. The company said it had stopped issuing from every intermediate under the G3 root.

eMudhra’s Account of the Key Ceremony

eMudhra told Mozilla that the eight keys came from a single key ceremony on April 30, 2025, run by its internal team on Utimaco hardware security modules, or HSMs, certified to FIPS 140-2 Level 3. The issuing CAs “were meant for export to our US and European data centers” to address data sovereignty, the company said, and it had introduced “an approved deviation” from its usual ceremony to test wrapping and unwrapping the keys.

According to eMudhra, a flaw in the ceremony script created a second, weaker key pair on the HSMs. The company said “these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar).” A certificate signing request, or CSR, contains the public key a CA asks to have certified, so each intermediate was issued for a weak key. “There were human errors in multiple steps of the process,” eMudhra said.

The company said its RSA intermediates went through a different path in the ceremony code and were not affected. It said its A and A-1 series of intermediates, generated on Entrust HSMs for use in India, were also unaffected. Jackson wrote that Mozilla could not recover those keys. eMudhra said its review is continuing, and it had not filed a full incident report by October 21.

The same six TLS intermediates were the subject of an earlier Mozilla incident report in June 2025. Sectigo engineer Rob Stradling, who maintains the crt.sh certificate search service, found that six revocation lists published by the intermediates had invalid signatures. eMudhra attributed that problem to a manual process that referenced the wrong CA key and published corrected lists on June 6, 2025, and Mozilla closed the report in July 2025.

In its October account, eMudhra told Mozilla that those revocation lists “were signed with the original private keys” and were later “resigned with flawed keys.”

Fixes Beyond the Browsers

By October 20 the disclosure site listed patched trust-store packages for Ubuntu, Debian, Fedora, Arch, Alpine and Gentoo, and fixes in Go, Python’s certifi, pip and uv, Rust’s webpki-roots, Electron and curl’s CA bundle. Node.js, the Bun JavaScript runtime and FreeBSD were listed as pending, and for Red Hat Enterprise Linux and its rebuilds, SUSE, NixOS and Amazon Linux 2023, the site gave manual workarounds rather than patched package versions.

The curl program that Apple ships with macOS, /usr/bin/curl, reads its own certificate file and had not been patched, and iTnews reported that it still accepted the compromised chain after Apple’s block. Ars Technica found Microsoft Edge on Windows 10 still connecting to what it called 12 vulnerable hosts on October 20.

The patched Go releases reject any certificate chain containing the eight keys, including on macOS and Windows, but only in programs rebuilt with them. Roland Shoemaker of the Go security team wrote that the team released the fix quickly because many users, especially on Linux, might not receive automated trust-store updates soon.

Cloudflare said it learned of the compromise at about 17:00 UTC on October 19 and completed mitigations across its CDN and server-side Zero Trust services at 19:20 UTC on October 20. “Browser maintainers were able to remediate the issue with a flip of a switch,” Cloudflare wrote. “We are making progress, but there’s much work still to be done.”

Valsorda told Ars Technica that “there will be a very, very long tail, IoT devices, Docker containers, forgotten Linux machines, unmaintained CLI tools that shipped their own copy of the roots.”

The disclosure site lists emSign Root CS CA – G3, the issuer of the two code-signing intermediates, in Microsoft’s root store only. Helme wrote that software signed under them could appear legitimate to tools that do not check revocation. Chrome said it did not need to block the code-signing intermediates because its TLS verifier does not accept them in a chain.

My Analysis

I have not seen a closer rehearsal for Q-Day in the web PKI than the past four days. For 17 months, anyone with eMudhra’s public certificates could compute the private keys of eight publicly trusted intermediate CAs. Shor’s algorithm gives the owner of a cryptographically relevant quantum computer, or CRQC, the ability to do the same to any RSA or elliptic-curve key it targets. Today that includes the root and intermediate keys of every public CA.

Chrome and Firefox blocked the six TLS intermediates in under three hours. Outside those browsers, the fix has to travel through operating-system, runtime, application and firmware update channels, and some systems will stay exposed for years. A CRQC will put every RSA and elliptic-curve CA where eMudhra’s eight intermediates were on October 17, and on that day the only clients protected will be those that already verify post-quantum certificates and have stopped accepting classical ones.

The eMudhra failure involved no quantum computer, and post-quantum cryptography would not have prevented it. A ceremony script that hands the wrong key to a CSR can do the same with an ML-DSA key. We now have measured response times for the first days of removing trust in one broken CA under close to ideal conditions. The post-quantum transition needs the same update channels to deliver new roots and new verification code, which is slower work.

Hours for Browsers, Years for Everything Else

Chrome and Firefox moved fast because Google and Mozilla own the update channel. CRLSets and OneCRL push a block to every Chrome and Firefox installation that receives their background updates, without a new release. Every other verifier waits for a packaged fix and for someone to install it, and often for a third party to rebuild software that has its trust compiled in.

Where the eMudhra fix stood on October 20, rechecked the next day

Sources: the disclosure site and the vendor statements linked above.

Linux is the hardest of the maintained platforms because it has no revocation mechanism that every application consumes. Red Hat’s shared trust store can mark certificates as distrusted for software that reads it through NSS, GnuTLS, OpenSSL or Java, but the distribution updates based on Mozilla’s list remove eMudhra’s root, which also cuts off the roughly 30,000 legitimate certificates under it until they move. Canonical has been building upki, a revocation service for Linux based on Mozilla’s CRLite data. Its VP of Engineering, Jon Seager, wrote in December 2025 that “Linux itself has fallen short by not providing consistent revocation checking infrastructure” for the remainder of userspace. Canonical’s October 6 announcement says Ubuntu 26.10 ships upki integrated with curl, and it does not say whether upki checks intermediate certificates.

Several fixes take effect only after a rebuild. Go’s new block on the eight keys is compiled into each binary, and Rust programs that use webpki-roots have their root list compiled in. A Go program on Linux reads the system’s root store, so a fixed distribution package protects it after a restart, but a command-line tool, Kubernetes operator or vendor agent built with an older Go release gets the block itself only when someone rebuilds and redeploys it.

Chrome and Mozilla stopped trusting AAA Certificate Services for TLS on April 15, 2025. Sectigo’s cross-signed copies of eMudhra’s new intermediates are dated May 14, 2025, so only clients outside those two programs would ever use them. Apple’s current trust store still lists AAA Certificate Services, valid until December 31, 2028, Microsoft’s store includes it according to the disclosure site, and every root bundle copied from Mozilla’s list before April 2025 includes it. Devices with those older bundles accept the Sectigo copies of the eight intermediates, and devices whose trust stores include the emSign root accept eMudhra’s own. Neither group gets any protection from revocation unless it checks for it.

Devices that never receive an update and do not check revocation will keep accepting the eight keys until the certificates expire, on December 31, 2028 for Sectigo’s copies and April 28, 2040 for eMudhra’s own, according to the certificate data on the disclosure site.

Valsorda compared the cleanup with Heartbleed, whose aftermath Zakir Durumeric and colleagues measured in their 2014 study, The Matter of Heartbleed. Of the Alexa Top 1 Million sites they found still vulnerable two days after disclosure, only 10.1% replaced their certificates in the following month, and 14% of those reused the same private key. From April 9 to 30, 2014, 4% of HTTPS sites in the Alexa Top 1 Million revoked their certificates. Those were server operators fixing their own servers. eMudhra’s cleanup has to reach every device and program that verifies certificates, and most of their owners will never hear the name eMudhra.

Finding those programs is the first job. One server can run several independent trust stores, such as the operating system’s, certifi in each Python environment, cacerts in each Java installation, the roots or blocks compiled into Go and Rust programs, and the copy built into each container image. A developer’s laptop also has browsers and Electron apps, several of which ship their own root stores. The eMudhra fix is complete on that machine only when the last of them is updated. I doubt many organizations could list them today.

No public log requirement like the one browsers enforce for TLS covers code-signing certificates, so no public record would show what anyone signed under eMudhra’s two code-signing intermediates between April 2025 and October 2026.

Why eMudhra Was the Easy Case for Defenders

Defenders had five advantages in the eMudhra case.

• Nothing depended on the eight keys. Chrome found no TLS certificates chaining to them in Certificate Transparency logs and eMudhra told Mozilla that none of them had issued end-entity certificates. Blocking the keys therefore broke no known website, unlike the root removal that followed.
• A replacement chain already existed. eMudhra’s RSA root is in the same trust stores. About 97% of the roughly 30,000 certificates that must move came through ACME, so most can be reissued without anyone touching a server.
• The finder reported it. Wayne proved control with a signed message and sent it to the people who could act.
• Certificate Transparency answered the browser question. Chrome could state that no forged certificate from these intermediates had been trusted by default in browsers that enforce the logs.
• The fix removed trust. Clients had to stop trusting something, which every trust store can do, instead of learning to verify a new kind of signature.

Against a CRQC, defenders who have not migrated lose all five.

The Same Exposure Across Every Classical CA Key

Shor’s algorithm factors RSA moduli and solves the elliptic-curve discrete logarithm problem, so a CRQC computes the private key behind whatever RSA or ECC public key it is given. On Q-Day there will be no classical root that is safe to move customers to, the way eMudhra is moving its customers to its RSA root.

An attacker also needs only one key. Chrome engineers David Benjamin and Joe DeBlasio wrote in Chrome’s post-quantum authentication roadmap that “a CRQC can still compromise the key of any trusted classical CA, forge a certificate, and impersonate the site,” whichever CA the site actually uses. They also wrote that “an attacker can always target the client’s weakest supported authentication option,” so adding post-quantum roots does not protect a connection until the client stops accepting classical ones.

In 2023 I wrote that once Q-Day arrives, browser vendors “will rush to disable or distrust older certificates.” Chrome and Mozilla have now done that for six intermediates in under three hours. On Q-Day, the same switch would leave every site without a valid chain unless post-quantum chains were already deployed and trusted.

Browsers also lose Certificate Transparency as a backstop. Under RFC 6962, logs sign their timestamps with ECDSA or RSA keys, so an adversary who can forge a CA’s signature can also forge a log’s promise that a certificate was logged. Chrome’s design for Merkle Tree Certificates, which I analyzed in February, makes inclusion in a public tree part of the certificate itself and signs the tree with post-quantum keys.

Wayne chose to disclose. For the 17 months of eMudhra’s exposure, nobody can show whether a client that ignores Certificate Transparency was attacked. An adversary with a CRQC has every reason to stay quiet, and defenders would then face that uncertainty for every classical key.

Code and firmware signing are harder to fix than TLS. A device whose only firmware trust anchor is a classical key fixed in its hardware, with no secure way to replace it, cannot be told to stop trusting it, which is the risk I first described in 2018 as Sign Today, Forge Tomorrow and now call Trust Now, Forge Later, or TNFL.

How Long a New Root Takes to Reach Devices

Removing trust took Chrome 1 hour and 40 minutes. Adding it takes years, and the best-documented case I know is Let’s Encrypt’s. Let’s Encrypt generated its ISRG Root X1 in a key ceremony on June 4, 2015 and used a cross-signature from IdenTrust “while we propagate our own root.” All major root programs trusted ISRG Root X1 by August 6, 2018, more than three years later.

In September 2020, 33.8% of Android devices still did not trust ISRG Root X1, because it is missing from versions before 7.1.1. Let’s Encrypt kept those devices working with a cross-sign from IdenTrust’s DST Root CA X3 that ran into 2024, relying on the fact that “Android intentionally does not enforce the expiration dates of certificates used as trust anchors.” Let’s Encrypt dropped the cross-sign from its default chain on February 8, 2024 and from its API on June 6, 2024, nine years after the key ceremony.

ISRG Root X1 was an RSA root, which every client already knew how to verify. A post-quantum root also needs code on the client that verifies ML-DSA signatures or Merkle tree proofs. Android 14 moved the root store into the updatable Conscrypt module, so newer devices can receive new roots without a full system update. Older devices change their roots only when the manufacturer ships a system update, if it ever does.

Any client that has not received the eMudhra block by now will not receive a post-quantum root any faster through the same channel, and it will also need new verification code. As I wrote in October, I measure crypto-agility as time-to-change, how long an organization needs to assess its exposure, decide, change and verify on its most important systems.

Nobody knows when a CRQC will exist, and root programs and regulators have set their deadlines without waiting for the answer. Chrome plans to launch its quantum-resistant root store, for Merkle Tree Certificates only, in the third quarter of 2027, and Apple and Let’s Encrypt have committed to the same certificate format. Executive Order 14412 directs the Office of Management and Budget to require US federal agencies to move high-value assets and high-impact systems to post-quantum signatures by December 31, 2031, as I covered in June. That date is five years and two months away, which is less time than Let’s Encrypt needed to stop depending on a cross-sign.

The Ceremony Error and the June 2025 Warning

Anyone with eMudhra’s certificates could compute the eight keys from April 30, 2025 onward, so the revocation reason eMudhra used, CA compromise, describes its loss of sole control rather than a theft. The private key for EM OV TLS CA – G3C was 4, which a patient attacker finds on the fourth guess.

In its account to Mozilla, eMudhra said the keys “were generated in hardware.” It used the phrase “created onboard” for both the original keys, which it says were generated as expected, and the weak ones. A correctly generated P-384 key falls below 256 with a probability of about one in $$2^{376}$$, and eMudhra’s ceremony produced eight such keys, so the weak keys did not come from correctly performed full-width random key generation. eMudhra says a flaw in the ceremony script created them, and its full incident report needs to say how. Until it does, my reading is that the fault was in the ceremony rather than the hardware. The HSMs’ FIPS 140-2 Level 3 validation covers the module, not the script that drove it.

The failure was visible from outside 16 months ago. When Sectigo’s Rob Stradling reported invalid signatures on the six revocation lists in June 2025, they had been signed with the original keys, according to eMudhra’s October account. Those keys did not match the weak public keys in the certificates. eMudhra fixed the lists by re-signing them with the keys that did match, which were the weak ones, and Mozilla closed the incident as a manual-process error. I could not find a question anywhere in that bug record about why each of these CAs had two keys.

Every CA that adds post-quantum keys will run new ceremonies on new HSM firmware, with scripts that have not run in production before. Composite certificates give one issuer a classical key and a post-quantum key, and dual hierarchies double the number of issuing keys a CA operates. eMudhra’s failure began with two key pairs per issuer and similar labels. Google said on October 20 that it had checked the keys in its root stores for the same failure, a test that is cheap once someone has named the failure. An ML-DSA key derived from a predictable seed has a public key that looks like any other. Wycheproof’s test vectors can confirm that an implementation computes the right ML-DSA key from a given seed, but no test vector can show that a ceremony supplied an unpredictable seed or certified the intended key.

What Security Teams Should Do Now

This Week

1. Find every trust store your systems use, beyond the operating system’s: language bundles such as certifi, the Node.js and Java runtimes, Go and Rust binaries, Electron apps, container base images, network appliances, and the CA lists your mutual-TLS services use to verify clients.
2. Where a client can block by public key, add the eight SPKI hashes the disclosure site publishes to its blocklist. Where it cannot, remove the four roots the disclosure site lists for the affected chains: emSign ECC Root CA – G3, AAA Certificate Services, emSign Root TLS CA – G3 and emSign Root CS CA – G3. If something you run still depends on AAA Certificate Services, fix that dependency, then test that every path to the eight keys fails.
3. Rebuild and redeploy Go programs, container images with stale trust stores and Rust programs that bundle webpki-roots, and install Electron app updates as vendors ship them.
4. Check whether any of your own certificates chain to emSign ECC Root CA – G3, and whether any software in your environment is signed under the two code-signing intermediates. Do not clear the resulting errors by turning off certificate verification.

Before Post-Quantum Roots Arrive

1. Measure your time-to-distrust. Distrust a test CA through your normal channels and record when each class of system stops accepting it. Plan for a post-quantum trust anchor to take at least that long, and measure the other steps separately: deploying verifiers that handle ML-DSA or Merkle tree proofs, deploying the new roots, and switching off classical authentication.
2. Add trust stores to the cryptographic inventory. A CBOM that lists the certificates you present, but not the roots each client trusts and who updates them, cannot answer the eMudhra question or the post-quantum one.
3. Move every publicly trusted TLS certificate to ACME, and test that renewals and chain changes reach the serving application without manual work. Most of eMudhra’s affected customers can change chains quickly because they use ACME, and Chrome’s draft policy for its quantum-resistant root store requires CAs to support ACME issuance and ACME Renewal Information.
4. Ask each vendor how trust-store changes reach its product and how long they take, and whether it can verify ML-DSA signatures or Merkle tree proofs today.

Wayne proved control of eight CA keys by signing “We have a problem here – Wayne” with each of them and sending the result to the people who could revoke them. The first owner of a CRQC will be able to produce the same proof for every RSA and elliptic-curve CA key in our trust stores. I would not plan on receiving that message.

From the author