eMudhra says a ceremony script cut eight CA private keys to one byte, after FIPS mode was switched off

eMudhra has published its full incident report into a set of certificate-authority keys that researchers were able to recover last month. The company says that, at a key-generation ceremony on 30 April 2025, a custom Python script read private keys out of a hardware security module. For eight ECDSA keys, a single line in that script truncated each private value to its leading byte, leaving a number smaller than 256. Those shortened copies, not the original keys, were the ones that got certified. Anyone with the public certificates could work the private keys out.

The same script also handled eight RSA keys. Those were not shortened, and their signatures still match the certified public keys. But the private material sat in the memory of a Python process on the ceremony computer, and eMudhra says it cannot show that this met its own rule for moving keys into or out of a cryptographic module. It revoked those eight RSA intermediates on 7 November, with the reason recorded as cessation of operation. The report, posted as comment 82 on Mozilla’s public incident bug, is the first time the company has set out that account in full. A post from Scott Helme, who pointed people to the filing, and a later note from Gergely Orosz brought the details to a wider audience.

eMudhra’s incident report is out! A Python script truncated their CA private keys to one byte?!

bugzilla.mozilla.org/show_bug.cgi?i…

— Scott Helme (@Scott_Helme) November 10, 2026

What the report says happened

The 30 April 2025 ceremony generated 16 subordinate CA keys in eMudhra’s B and C series: eight ECDSA P-384 keys under the company’s G3 hierarchy, and eight RSA-4096 keys under G2. The keys were created on Utimaco hardware security modules at an existing WebTrust-certified data centre, because the HSMs ordered for eMudhra’s US site had been delayed. The plan was to move them later to Crypto4A modules in the US and EU. Moving keys between HSMs from different vendors is limited, the report says, so the PKI operations team wrote a Python script to wrap each key for transport and unwrap it again. The 30 April round trip was a rehearsal of that transfer. The source module’s FIPS-approved mode was switched off for the wrap/unwrap step, which the report describes as an approved deviation written into the ceremony script.

For the ECDSA objects, a single line in that read-back truncated the private value to its leading byte, so the re-created object held a scalar below 256; this re-created object (not the originally generated key) was used to produce the CSR and was certified.

eMudhra full incident report, Bugzilla 2083449

After the wrap came back, the script read the unwrapped private key out of the module into memory on the ceremony computer and built a new key object from that copy. The rebuilt ECDSA objects carried labels almost identical to the originals, so the weak copies were the ones sent for signing, including to Sectigo for cross-certification. The ceremony did not test the strength of the CA private key, and it did not compare the certified public key with the key that had first been generated. eMudhra says either check would have caught the mistake. The weak keys still produced valid signatures, and the certificates passed linting and two WebTrust audit cycles. The company says the HSMs themselves worked correctly, and that the fault sits in the host-side script and the process around it. The script ran only on an isolated ceremony host, it says, and was not part of its emCA software.

What followed, and what still has to happen

A researcher reported the recoverable ECDSA keys to Apple, Chrome, Microsoft, Mozilla and eMudhra on 17 October. Mozilla confirmed the keys independently the same day and blocked the affected intermediates in Firefox through OneCRL. eMudhra revoked the eight ECDSA intermediates the next day, with the reason cACompromise. Sectigo revoked its eight cross-certificates of that set on 19 October. Mozilla and Chrome went further, removing trust in the parent emSign ECC Root CA – G3, to protect clients that do not reliably check revocation. The eight weak ECDSA intermediates themselves had issued no end-entity certificates. The distrust of the G3 root still affected certificates that chained to it by other routes. eMudhra’s status page puts that population at about 30,800 certificates, belonging to a university federation in the United States, which was first moved onto eMudhra’s G1 RSA root and is now being moved to another provider.

The RSA G2C issuers, unlike the weak ECDSA set, had been in production since May 2026 and had issued end-entity certificates. The report says those subscribers have been migrated, and that the G2B RSA issuers had not issued any end-entity certificates. eMudhra has said it will leave the public TLS business. Remaining issuance from the emSign Root CA – G1 hierarchy is due to stop before 16 November. The status page, last updated on 5 November, says Chrome and Firefox will stop trusting new G1 certificates with an SCT after 16 November, and that Apple will remove trust in the G1 hierarchy on 30 November, including certificates issued earlier. The company has appointed KPMG as an independent reviewer, with that review due on 4 December.

The report also revisits a June 2025 incident, tracked as Bug 1970728, in which CRLs for the same G3B and G3C TLS intermediates failed to verify. eMudhra now says those CRLs had been signed with the original, strong keys, while the certificates had been issued over the re-created weak ones. At the time, the company re-signed the CRLs with the objects that matched the certificates, and treated the problem as a key-configuration error. The new report calls this an early indication of the same defect, resolved at the symptom level without reaching the underlying cause.

I CANNOT believe the report: it proves that eMudhra is a clown show, and was never fit to be a CA:

The point of a HSM (hardware security module) is that the private key NEVER leaves it. Guess what eMudhra did: it turned off FIPS mode (WTF?!) and copied out the private key 😱 https://twitter.com/Scott_Helme/status/2120225704964976704

— Gergely Orosz (@GergelyOrosz) November 11, 2026

People following the bug have asked eMudhra to publish the ceremony script and the logs that go with it. Those files were not attached to the report. eMudhra says it has no known case of the weak keys being misused against a certificate it had issued, and that later inspection of logs cannot reliably show how the RSA key material was handled once it was in process memory. Browser and root-program staff have also noted that, after the October disclosure, certificates signed with the compromised ECDSA keys appeared in Certificate Transparency logs, including proof-of-concept names, often without pointers to eMudhra’s revocation services. The report closes with a deadline: no more issuance from the G1 hierarchy after 16 November, something Certificate Transparency can be used to check.