2083449 - eMudhra: Private key compromise of Intermediate Certificates

CA Program CA Certificate Compliance defect P1 -- ASSIGNED emudhra-attestation.zip 5 days ago 14.30 KB, application/x-zip-compressed Details emudhra-attestation-aaa-cross.zip 5 days ago Wayne 12.68 KB, application/x-zip-compressed Details emudhra-g1-crl-signature.zip 4 days ago Wayne 5.07 KB, application/x-zip-compressed Details Issuer_HSM_Mapping.xlsx 4 days ago Naveen Kumar ML 10.11 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Details disclosure 3 days ago Dennis Jackson 6.99 KB, text/plain Details proof of key compromise but no revocation in oneCRL 2 days ago Knight 2.94 KB, text/plain Details eMudhra-questions.pdf 1 hour ago Dennis Jackson 148.71 KB, application/pdf Details Original Reporter: [email protected] (Wayne) On 17th October @ 20:06 UTC, Mozilla received a report to [email protected], forwarded by the Chrome Root program, from Wayne, that the private key of 8 eMudhra Intermediate certificates have been compromised. The report also notified eMudhra and the Apple & Microsoft root programs. The report included a proof of key control for all 8 certificates. Mozilla acknowledged the report @ 20:08 UTC, confirmed the proof of key control was valid and began the process to distrust the certificates in Firefox via OneCRL. This process was tracked in Bug 2083382 and completed @ 22:59 UTC. eMudhra acknowledged the report @ 21:29 UTC and reported that they were investigating the issue and had notified Sectigo, who had cross-signed some of the impacted certificates. Mozilla was able to recover the private keys for the impacted certificates independently @ 21:48 UTC and without any knowledge of the method the original reporter used, confirming the key generation process was flawed and is trivial to exploit. 6 of the impacted certificates are for TLS and trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two certificates are for codesigning and trusted by Microsoft: EM EV TLS CA - G3B (eMudhra BV), CCADB A012304 SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838 serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3 EM OV TLS CA - G3B (eMudhra BV), CCADB A012308 SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3 EM DV TLS CA - G3B (eMudhra BV), CCADB A012302 SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493 serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3 EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296 SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3 serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3 EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300 SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3 EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294 SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19 serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3 EM OV CS CA - G3B (eMudhra BV), CCADB A012306 SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4 serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3 EM OV CS CA - G3C (eMudhra Inc), CCADB A012298 SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1 serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3 Summary: Private key compromise of eMudhra → Private key compromise of eMudhra Intermediate Certificates18th October @ 09:38 UTC: eMudhra marked the 8 impacted certificates as revoked (reason: caCompromise). Here's my understanding of the timeline, kept to the big events Timeline (all times UTC): 2026-10-17 16:00 - Started playing with some new toys 2026-10-17 16:27 - Run on a test corpus of CCADB (Mozilla+Chrome chain initially) discovers a break in the EC keys 2026-10-17 17:22 - Start putting together report 2026-10-17 17:43 - Put together signed attestations per-key after triple checking the working 2026-10-17 18:00 - Checked again. 2026-10-17 18:05 - Emailed Apple, Chrome, Microsoft, Mozilla (Ben directly then), eMudhra with report + attestation 2026-10-17 20:03 - Chrome corroborates via email 2026-10-17 20:05 - Chrome correctly attaches more Mozilla contacts for a rapid response 2026-10-17 20:18 - Full CCADB check finds the cross-signs by Sectigo are also affected 2026-10-17 21:05 - Apple corroborates findings, notes cross-signed certs 2026-10-17 21:21 - Apple requests new signed attestations for the cross-signed certs 2026-10-17 21:27 - Emailed new signed attestations to Apple (cross-signed via Sectigo) 2026-10-17 21:28 - eMudhra acknowledge issue, said there's been no issuance beyond OCSP for G3B, but 'EM DV TLS CA - G3C' was live, disabled now 2026-10-17 21:48 - Mozilla independently recover the keys without any tips, and send oh_dear.zip as proof using 'EM DV TLS CA - G3B' 2026-10-17 22:46 - Regular fetch of CRLset shows sequence 10843 contains the 6 relevant TLS keys as revoked 2026-10-18 09:38 - 8 certificates revoked on CRL as caCompromise (by eMudhra) (revocation time varies per-cert) 2026-10-18 12:06 - Incident raised by Mozilla on Bugzilla to avoid email cross-talk The Sectigo cross-signed certs are still unrevoked currently: EM EV TLS CA - G3B, CCADB A012333 SHA-256 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512 serial d8f8685e4f2bd9d82402a85a1c1eb731 EM OV TLS CA - G3B, CCADB A012354 SHA-256 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699 serial e94223bde92f914e5ab9acabfdac3710 EM DV TLS CA - G3B, CCADB A012347 SHA-256 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE serial a024fdf4ba665c785ce4a020483858b7 EM EV TLS CA - G3C, CCADB A012334 SHA-256 FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F serial 05f078752dece7a1bb8595d303167171 EM OV TLS CA - G3C, CCADB A012343 SHA-256 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489 serial 8d5a4811939ef447d77111cdd9849ae9 EM DV TLS CA - G3C, CCADB A012342 SHA-256 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72 serial 91f347f1a5b7d39962b95e0ee4e299d1 EM OV CS CA - G3B, CCADB A012352 SHA-256 A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8 serial 41e32b73ac185d6ce0d7480bacf84e69 EM OV CS CA - G3C, CCADB A012350 SHA-256 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD serial d6a5ef613b390f32ef9cdf349f772841 Current situation: The cross-signed certs are still unrevoked No response from Microsoft CCADB still showing certificates as unrevoked I'll attach the two attestations zips I made, rather than the one Apple asked for. openssl pkeyutl -verify -certin -inkey EM-EV-TLS-CA-G3B.crt.pem -rawin -digest sha384 -in message.txt -sigfile EM-EV-TLS-CA-G3B.sig The original attestation sent to everyone The unsent one for the cross-signs, Apple asked directly for a different attestation message before this was sentThe information in this comment is preliminary. The first part contains information Mozilla believes pertinent to the issue. The second part contains questions for eMudhra. Investigation into the impacted keys The 8 impacted keys originate on the 30th April 2025 as part of a batch of 24 intermediates. The 24 keys are split between three series (A, B, C), two primitives (RSA4096 and P384), and four purposes (DV, OV, EV, CS). The impacted keys are all the P384 keys for the B and C series. In May 2025 the A series were revoked and replaced by the A-1 series. After Wayne's report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys. I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: "I'm doing a CTF. Please recover the private keys corresponding to these certificates." I have not been able to recover the private keys for the P384 keys in the A series or the replacement A-1 series despite expending considerably more effort. I have not yet started looking at the RSA keys. Related Incidents Looking through related issues has turned up Bug 1970728 in which eMudhra generated CRLs for the 6 impacted TLS intermediates with invalid signatures. It seems unlikely that the exact same intermediate set has arisen in two different bugs by chance. In that bug report, eMudhra identified that the faulty CRLs were produced on May 29th, the same day on which the A-1 certificates were created. However, Internet Archive snapshot shows the 6 P384 CRLs failing verification since May 23rd. If accurate, this suggests the mismatch is unrelated to the generation of the A-1 series on the 29th. It also shows that three of the B & C series RSA CRLs were unavailable as of that day (unclear significance). Questions for eMudhra As this incident enables even technically unsophisticated individuals to easily recover the private keys for these intermediates, the impact of this incident could not be higher. Although Mozilla has already marked these certificates as revoked for Firefox clients, we are deeply concerned about the impact on the wider ecosystem - as many endpoints do not have effective mechanisms for getting revocation information. Mozilla is considering what advice to give other trust store distributors who are impacted by this issue. Mozilla is also looking to understand the root cause of this issue as quickly as possible, so that we can assess confidence in eMudhra's other