What happened
BleepingComputer reports that both sets of certificates were affected by a custom Python script used to transfer private keys between hardware security modules (HSMs) in April 2025. The Hacker News adds more detail from eMudhra's full incident report. A single line in the script cut each of the eight October-compromised ECDSA keys to one byte.
The second batch is a different kind of problem. The eight newly revoked CAs use RSA keys. According to The Hacker News, eMudhra reached its view in early November, after discussions with browser root programs. The script did not shorten those keys, and every signature still verifies against the certified key. But their private components, such as the private exponent and one of the primes, sat in the memory of a Python process on the ceremony computer. eMudhra says it therefore cannot demonstrate compliance with its own rule, CPS §6.2.6, on moving keys in and out of an HSM.
Compromise versus unverifiable handling
These are two different findings, and they shouldn't be blurred together.
| First eight (October) | Additional eight (November) | |
|---|---|---|
| Key type | ECDSA P-384 | RSA-4096 |
| Problem | Private values truncated to one byte, so they are recoverable | Key material handled in host memory, with compliant handling not demonstrable |
| Weakened? | Yes | No, per eMudhra |
| End-entity certificates | None issued from the ECDSA issuers, per the Hacker News account | 195 listed |
| Evidence of misuse | None known | None known |
The Hacker News says the new batch includes six TLS intermediates and two code-signing intermediates. Its list names 195 certificates: 130 from EM DV TLS CA - G2C, 63 from EM OV TLS CA - G2C, and two from the code-signing CA EM OV CS CA - G2C. BleepingComputer reports that some of the RSA intermediates had been issuing since May 2026, with the last certificate issued on November 3, and that affected customer certificates have been replaced or migrated.
Nobody has shown that the RSA keys were stolen or misused. The revocation rests on eMudhra's inability to prove compliant handling. BleepingComputer notes that the company says it has not detected any evidence that the compromised keys were used maliciously. That claim covers the compromised keys, and it doesn't amount to a clean bill of health for every certificate in the hierarchy.
The credibility problem
The timeline is awkward for eMudhra in three ways.
- A reversal. On October 19 the company told Mozilla's bug tracker that the RSA issuers went through a different path and were not impacted. The Hacker News reports that the full report says the RSA keys went through the same read-back step. eMudhra says its earlier answers reflected only what its teams had gathered at that point.
- A missed warning. BleepingComputer reports that in June 2025 eMudhra detected certificate revocation lists signed with private keys that did not match the corresponding CA certificates. It fixed the symptom but didn't investigate the cause. The report now treats that mismatch as an early warning of the faulty process.
- Missing controls. According to BleepingComputer, eMudhra did not verify the strength of generated private keys or check that the keys used for certification matched those originally created in the HSM. The Hacker News adds that the weak keys still passed linting and two WebTrust audit cycles. The company says the HSMs themselves worked correctly and puts the fault in its own script and process controls.
Participants in the Mozilla thread are pressing for answers. The Hacker News reports they have asked why the new CAs were revoked with the reason code cessationOfOperation rather than a key compromise code. Some want the script published, and some ask how private keys could leave the HSMs at all.
What this means for Windows and Edge
The practical dates matter more than the root-cause debate. Microsoft's security response post says it is removing the remaining eMudhra root certificates across its products and services, starting November 16, 2026. The post says some changes roll out automatically on November 16, and others depend on servicing updates or upstream partner releases.
- Windows: Microsoft will remove the remaining 10 eMudhra roots from the Windows trusted root list through the HTTP endpoint Windows devices use for automatic certificate trust updates.
- Edge and WebView2: An update delivered via the PKI Metadata component will fully remove default trust for the remaining roots, including emSign Root CA - G1 and emSign Root TLS CA - G1.
- Azure Linux: Microsoft will remove the affected roots and refresh Azure Linux VM and container images on November 16.
- .NET containers: These follow upstream ca-certificates package updates, starting with Azure Linux on November 16, 2026.
This builds on the earlier October action. gHacks reports that KB5134133 covers Windows 11 24H2, 25H2 and 26H2, while KB5134125 covers Windows 10 21H2 and 22H2. Those updates were aimed at machines that can't receive automatic trust updates. Microsoft's advice was to identify devices that are offline, cannot reach Microsoft's certificate update service, or have automatic CTL updates disabled.
Practical steps for admins
The general approach below is my own synthesis from the reporting. It isn't a Microsoft procedure.
- Inventory by issuer. Look for certificates issued by the G2C TLS and code-signing issuers, not just the original ECDSA set. The Hacker News says holders can check eMudhra's list or search Certificate Transparency logs for the revoked G2C TLS issuers.
- Check the chain, not just the leaf. If eMudhra or emSign appears anywhere in a certificate's chain, plan a replacement. A hosting-industry guide advises checking the issuer and root in the browser's certificate details.
- Review code signing. Two of the new revocations are code-signing intermediates. Check for any dependencies on that hierarchy.
- Confirm trust updates reach endpoints. Offline and air-gapped Windows systems, and any machine with automatic certificate updates disabled, won't get the November 16 change through the usual route.
- Watch other vendors' timelines. The Hacker News reports that Chrome and Firefox will not trust G1 certificates issued after November 16, and that Apple ends trust in all G1 certificates on November 30. Its macOS note says the updates also drop five roots, including emSign Root CA - G1, from /etc/ssl/cert.pem.
What's still open
- Exit from public TLS: BleepingComputer reports that eMudhra plans to stop issuing under its remaining G1 hierarchy by November 16. It is exiting the publicly trusted TLS business.
- Independent review: KPMG's findings are expected by December 4. The Hacker News adds that eMudhra's inventory of all its CA keys is due November 30. These are scheduled milestones, not findings.
- Real-world exposure: The Hacker News notes that browsers enforcing Certificate Transparency could not have been fooled. Whether anyone used the October keys against software that skips that check is unknown.
Analysis
The fix at eMudhra was the easy part. A wrong key length can be caught by a basic test, and the ecosystem now seems likely to add such checks. The harder lesson is that a CA's hierarchy is only as trustworthy as its ability to prove how its keys were handled. Here a one-time wrap-and-unwrap workaround, done without strength checks, left both batches of keys in doubt. One batch was provably weak, and the other couldn't be shown to be safe.
Some of the fault also lies outside eMudhra. Mozilla's thread shows Chrome's team acknowledging gaps in the ecosystem's weak-key screening. Checks for small elliptic-curve private scalars weren't part of standard linting, and Google's internal pipeline didn't cover dormant CA certificates disclosed only to the CCADB. That doesn't excuse eMudhra's handling, but it does show that one script bug sat unnoticed for roughly 18 months.
For most Windows users, the November 16 root removal will happen quietly through automatic updates. For admins with legacy emSign chains, offline systems or code-signing dependencies, it is a deadline.