For nearly 18 months, anyone could derive the private keys of eight publicly trusted intermediate CA certificates from their public keys. No HSM was breached. No insider walked out with a key. The public key was simply enough.
This incident illustrates risks inherent in complex, interconnected PKI ecosystems. Even mature cryptographic infrastructure can encounter vulnerabilities, and the broader industry’s ability to respond with speed is what determines the successful resolution of an incident. It also describes what a cryptographically relevant quantum computer (CRQC) will do to every RSA and ECC key we rely on. Every organization got a fire drill rehearsal of the post-quantum trust problem, at the scale of one CA.
What happened
On 30 April 2025, eMudhra (emSign) ran a key ceremony for eight intermediate CAs, six for TLS and two for code signing. By eMudhra’s account in the public Bugzilla thread, a flawed ceremony script created a weak key pair alongside each strong one, and because the labels looked similar, the weak keys went into the CSRs. The P-384 private keys should have been random 384-bit numbers. They were integers below 256. One was 4.
eMudhra’s G3 roots signed them, and Sectigo cross-signed the same keys, giving each broken key two paths to trust. On 17 October 2026, a researcher proved it by signing “We have a problem here” with all eight keys and sending it to the root programs.
Browsers aren’t the whole internet
Chrome blocked the six TLS keys by public key within 100 minutes, covering the Sectigo cross-signs too. Firefox followed within three hours; Apple, Android and Microsoft within three days. Because browsers enforce Certificate Transparency and no forged certificate was logged before the block, browser users were never exposed.
That protection rests on a classical assumption: CT log signatures are unforgeable. A CRQC breaks that assumption. Before Q-Day, CT log signing keys will need to migrate to ML-DSA or a hybrid scheme, or the protection browsers relied on today disappears too.
Most enterprise machine-to-machine traffic runs through clients with neither pushed revocation nor CT: Go services, Python scripts, Java services, API gateways, firmware updaters. Within a day of the disclosure, someone used a reconstructed key to mint more than 105,000 certificates for google.com. Browsers rejected every one. A bundle-only client would not.
Why distrusting the G3 root doesn’t close the exposure
The intermediates are revoked, Mozilla has pulled emSign ECC Root CA – G3 from its root store, and Chrome is removing it too (effective October 27, 2026). Five gaps remain.
- Revocation only helps clients that check it. Clients that never fetch a CRL or OCSP response, or that soft-fail, ignore it.
- Root removal moves at the speed of your slowest bundle. Node.js shipped patched releases on 21 October, but only upgraded runtimes get them; Bun was still pending at the time of writing. Container images keep the old bundle until rebuilt.See this runtime-by-runtime breakdown for specifics.
- The cross-signs are a second path. Even with the emSign root gone, Sectigo’s AAA root, still in other root lists and bundles, lets a client that skips revocation chain to a compromised key.
- Static trust stores don’t get the memo. Appliances, load balancers, IoT and OT devices carry bundles baked into firmware, and custom Java truststores are the software equivalent.
- Code signing has no CT. Two of the eight were code-signing CAs, so evidence of forged signatures would have to surface through malware samples and telemetry. What was signed in those 18 months may never be fully known.
Why this is the harvest now, forge later rehearsal
Others have framed post-quantum signature risk as “trust now, forge later”: the idea that today’s signatures can be forged once a CRQC arrives. This incident makes the threat concrete in a way that abstract post-quantum writing doesn’t, because it happened without a quantum computer. The attack was classical: a public key was simply enough to reconstruct the private key. A CRQC does the same thing, at scale, against keys that look perfectly secure today.
The harvest is already done: every public TLS certificate sits in CT logs, and every root ships in trust stores on billions of devices. Early quantum machines will be scarce, so attackers will target the highest-leverage keys. eMudhra showed which: one intermediate CA key can impersonate any website or sign any software.
A quantum break won’t be contained to eight keys. Defenders won’t know which keys were recovered, and no CRLSet can distrust RSA and ECC and leave anything standing. The fallback must exist beforehand: post-quantum roots (ML-DSA or hybrid) in trust stores, verifiers that understand them, and boot chains that accept them.
That’s why signatures face different time pressure than encryption. Harvested ciphertext is a bounded confidentiality problem. A root or firmware-signing key still trusted when a CRQC arrives is an integrity problem: a forged update installs because it is correctly signed, and nothing raises an alert.
What to do this week
Ensure no client you own trusts these eight keys by any path.
Contain. Block the eight intermediates by public key using impacted-intermediates.json, covering the eMudhra and Sectigo certificates at once. Where you can’t, distrust every root they chain to, listed in roots.json, including Sectigo’s AAA Certificate Services, after checking what else depends on it.
Propagate. Updated bundles protect only what gets rebuilt and redeployed, including Go services, container images and packaged apps.
Verify. Point clients at the disclosure site’s test hosts. A connection that succeeds without a certificate error still trusts a compromised key.
Own the long tail. Give every appliance, gateway, IoT and OT device, and custom Java trust store an owner and a date.
Shrink your blast radius. Replace certificates chaining to the G3 root before Chrome’s October 27 root store update breaks them (eMudhra estimates ~30,000 need reissuing), and review allowlists and EDR policies for anything signed under the two code-signing CAs.
What to do before Q-day
Longer term, you need two capabilities: crypto posture management – knowing where trust lives – and crypto-agility – the ability to change it on demand. Start by managing trust stores, not just certificates. Discover every OS store, runtime bundle, Java trust store, container image and appliance, record which roots each one trusts, and be able to push and verify changes across all of them. Adding post-quantum roots is the same operation as removing emSign, in reverse. Extend that visibility into a CBOM of your applications, crypto libraries, algorithms and trust anchors.
Then for each key in your hierarchy, ask these questions:
- How long must this key stay trusted?
- Can its verifiers be updated in the field?
- What cascades from it if it’s forged?
A root that must stay trusted for decades, whose verifiers are baked into firmware, and whose compromise lets an attacker sign arbitrary code scores high on all three. That is your migration priority. Roots, firmware-signing keys and code-signing keys come first – not because they’re more common, but because their blast radius is unbounded and their verifier chains are hardest to update.
At the same time, stop buying tomorrow’s long tail. Require a PQC or hybrid verification roadmap for long-lived industrial, automotive, medical and network devices. CNSA 2.0 expects quantum-resistant software and firmware signing exclusively by 2030, and NIST IR 8547 proposes disallowing quantum-vulnerable algorithms after 2035. As PQC brings new HSM firmware, algorithms and ceremony scripts to every hierarchy, check each key and CSR independently before signing.
Crypto-agility must become a core enterprise security capability. Organizations need more than knowledge of their cryptographic exposure. They need the ability to update trust anchors, rotate keys, replace vulnerable algorithms and validate changes across complex environments with minimal disruption.
Run the eMudhra incident clock on a root you depend on: how long does it take your organization to discover every client that trusts it, push updated bundles to all of them, and verify the result? If the answer is longer than 24 hours, you’ve found your Q-Day gap. That time-to-distrust today is the same motion the PQC migration will demand, at far larger scale and with no fallback root to absorb the lag.
eMudhra just ran our Q-Day fire drill
The browser response worked because the damage was limited to eight keys and every other root was still there to fall back on. The long tail is a different story: binaries, images, appliances and devices that trust only their own bundles will keep trusting these keys for weeks or months, or until someone remembers they exist.
Q-Day will widen that gap, with every RSA and ECC key at risk and no unaffected root to fall back on – in a world running on orders of magnitude more machine and agent identities than today.
That is the identity security challenge of the AI and post-quantum era that AppViewX is solving today: trust governance at machine speed, and the ability to change any key, trust anchor or algorithm before a threat forces the decision.
Speak to an expert from AppViewX today on how you can take steps to introduce crypto-agility and continuous crypto posture management across your organization.
Tags
About the Author
