“The in‑house Python script behind eMudhra's October key compromise has now cost the company 8 more of its intermediate certificate authorities (CAs), even though it did not weaken their keys.”
The April 30, 2025 key ceremony and the Python wrap‑and‑unwrap
According to eMudhra’s incident report posted to Mozilla’s bug tracker, the two problems that produced the October compromise began at a single key ceremony on April 30, 2025. On that day the company generated 16 CA keys on Utimaco HSMs intended for Crypto4A HSMs at US and EU sites. Because moving keys between different HSM vendors is limited, the company’s PKI operations team wrote a Python script to wrap each key for transport and unwrap it again as a one‑time practice run. The source HSM’s FIPS‑approved mode was switched off for the exercise as an approved exception.
How the script corrupted ECDSA keys and exposed RSA key material
The report says a single line in the script truncated the private value of eight ECDSA private keys to their leading byte during the read‑back, producing rebuilt keys with severely reduced private values. Those weak keys nevertheless generated valid signatures, and their certificates passed linting and two WebTrust audits unnoticed. The Hacker News reconstructed all eight weak keys from their public certificates; the smallest private value recovered was 4 and the largest was 237.
The same read‑back step also placed the private parts of eight RSA keys — private exponent and one prime, among other values — into the ceremony computer’s Python process memory. The company says the script did not shorten those RSA keys and that every signature still checks against the certified key, but it “cannot positively demonstrate that this key material was in compliance with CPS §6.2.6,” its own rule on moving keys into and out of an HSM, because logs and files from the ceremony computer cannot reliably show how the material was handled.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleRevocations, reason codes, and timelines
eMudhra revoked the eight ECDSA CAs in October using the CA‑compromise reason code. After further discussions with browser root programs and additional investigation, the company revoked eight RSA CAs late last week with the reason code cessationOfOperation rather than keyCompromise. Participants on the Mozilla bug thread have asked why emudhra chose cessationOfOperation.
Of the 195 certificates listed as affected, 130 came from EM DV TLS CA - G2C, 63 from EM OV TLS CA - G2C, and 2 from the code‑signing CA EM OV CS CA - G2C. Six of the eight newly revoked intermediates were for website (TLS) certificates and two for code signing; four of the eight had been put into production in May. The company says all holders have been moved to new certificates; the newest certificate in the list was issued days before the revocations.
Platform actions and emSign phase‑out
eMudhra, which sells certificates under the emSign brand, announced on October 22 that it will exit the publicly trusted TLS business. The company’s phase‑out schedule and vendor updates set concrete dates: Microsoft will begin removing the 10 remaining eMudhra roots, including emSign Root CA - G1, on November 16. According to the company’s schedule, Chrome and Firefox will not trust G1 certificates issued after November 16, and Apple will end trust in all G1 certificates, including older ones, on November 30.
Apple also specified that macOS 27.2.1, 26.7.3 and 15.8.3 will stop bundled command‑line tools such as curl and git from accepting the compromised TLS CA certificates and will drop five roots, including emSign Root CA - G1, from /etc/ssl/cert.pem; tools relying on that file may therefore fail to verify some sites that chain to those roots.
How technologists, browser vendors, and emSign certificate holders are responding
- Technologists and security teams: Investigations already flagged invalid CRL signatures in June 2025; those were corrected at the time by re‑signing with the weak keys. Teams now must verify certificate chains against new keys and confirm that any local tools or automation that rely on the retired roots are updated before platform removals on November 16 and November 30.
- Browser and platform vendors: Discussions with browser root programs led to the late‑week revocations and informed the choice of reason codes; vendors are implementing the phase‑out timetable already reflected in Microsoft and Apple updates.
- emSign certificate holders and enterprises: Holders can find affected certificates in eMudhra’s published list or by searching Certificate Transparency logs for the revoked G2C TLS issuers. The company says all affected holders have been moved to new certificates, and remaining G1 issuance is due to stop before November 16.
KPMG, hired as an independent reviewer, is due to finish its review by December 4, and eMudhra’s inventory of all CA keys is due November 30. The company says it knows of no case of misuse; at the same time, a disclosure site run by Dennis Jackson notes that anyone holding one of the October keys could have impersonated any website. Browsers that enforce Certificate Transparency could not have been fooled, while whether the keys were used against software that skips that check remains unknown.
The record ends with tangible next steps and an open question: independent review and inventory deadlines are set, platform removals are scheduled, and eMudhra has shifted affected holders to new certificates — but whether any of the compromised key material was ever exploited is not yet resolvable from the facts the company has published.
