The eMudhra Entropy Failure: Exposing TLS and Code Signing Audit Blind Spots
In this post, we examine why the eMudhra intermediate CA weak private key generation incident is not just an isolated operational failure, but a fundamental critique of the Web PKI ecosystem. It reveals an important compliance gap. We provide insight into the shortcomings of limited procedural audits and how they fail to verify the mathematical reality of a weak entropy source.
We would like to thank the team at Mozilla for the detailed information on their ongoing bug tracker, which can be found on this source: Mozilla Bug ID 2083449. All the latest information related to this cryptographic security issue can be found on this source.
Authors: Dr Angelique Faye Loe & Prasanth Sundararajan
Summary of our key findings
Incident Scope & Cryptographic Failure: On April 30, 2025, a Key Generation Ceremony produced 24 subordinate intermediate CAs (ICAs). A configuration error during a script execution resulted in eight of these CAs receiving weak private keys for the ECDSA digital signature algorithm over the NIST P-384 curve with near-zero entropy, leaving them vulnerable to trivial mathematical recovery. The incident is somewhat limited as no end entity certificates had been issued from the ICAs in question prior to their ultimate revocation.
Audit & Compliance Blind Spots: Although eMudhra maintained active CA/B Forum membership during the key generation and indicated that these keys were generated inside a certified FIPS 140-2 Level 3 HSM (Utimaco Se-Series Gen2), the subsequent WebTrust compliance audit conducted by BDO does not explicitly cover the auditing of the entropy source at the time of key generation. This highlights how traditional auditing frameworks focus mainly on administrative controls, physical security, and procedural checklists rather than validating the mathematical integrity of generated key material. (Note the claim of key generation inside a FIPS 140-2 Level 3 HSM is currently the main aspect under scrutiny).
Limitations of Current Baseline Requirements: The CA/B Forum Server Certificate and Code Signing Baseline Requirements (Section 6.1.1.1) mandate strict procedural controls, witness sign-offs, or video logging for key ceremonies, but omit any requirement for pre-issuance entropy source verification. As a result, these compromised CAs remained live for 18 months until independent researchers detected the failure to use a strong entropy source.
Proposals for Ecosystem Improvement: To prevent similar failures across the Web PKI landscape, CA/B Baseline Requirements should evolve to mandate entropy source validation and other technical verifications on all root and intermediate CAs. Additionally, adopting public transparency practices, such as publishing video feeds of key ceremonies similar to IANA’s DNSSEC Root Key ceremonies, would improve accountability to relying parties and auditing bodies.
What we know about eMudhra
It is easy for sensationalist headlines to blame the Certificate Authority in question, especially when the issue involves private keys so mathematically trivial that their values, d = (4, 56, 66, 115, 155, 156, 230, 237), could be recovered on a pocket calculator. Security researchers traced the weak private key generations back to an April 30, 2025 ceremony which generated 24 ICAs, 8 of which were affected by this entropy failure across their ECDSA P-384 key pairs. Rather than stopping at an obvious operational error, we wanted to dig into the broader systemic questions this raises, and our questions broadly mirror those currently under scrutiny in the public tracker: Mozilla Bug ID 2083449.
eMudhra: a Full CA/B Forum Member
To establish governance context, we first verified eMudhra's status within the CA/Browser Forum. Although less familiar to non-specialists than giants like DigiCert or GlobalSign, eMudhra holds full CA/B Forum membership. Archived records from the Wayback Machine in early October 2026 explicitly list them among active members, and official teleconference minutes from January 10, 2019 mark their formal admission under Item 4.
Membership carries explicit responsibilities: eMudhra was required to maintain and conform to comprehensive CP and CPS documents detailing the exact operational, physical, and technical controls required during key generation ceremonies that met or exceeded the CA/B Forum Baseline Requirements.
eMudhra: the CP/CPS contents
As of April 30, 2025, eMudhra’s emSign PKI operated under CP/CPS version 1.18, published on March 14, 2025.
The governing CP/CPS contains two key mandates regarding key generation:
‘6.1.1. Key Pair Generation Issuing CA key pairs are generated in a secure manner as part of a key ceremony in a physically trusted environment by trusted personnel. Issuing CA key generation is carried out in a secure device that is at least FIPS 140-2 Level 3 compliant.’
'6.2.1. Cryptographic Module Standards And Controls All CA Private Keys under emSign PKI must be generated and maintained in a Hardware Security Module that is compliant with Federal Information Protection Standards 140-2 Level 3+.'
eMudhra: the Hardware Security Module
Disclosures on the Mozilla bug tracker from an eMudhra representative identified the Hardware Security Module (HSM) used during the ceremony as a Utimaco CryptoServer Se-Series Gen2.
The first logical check is whether this module held active FIPS 140-2 Level 3 validation during the April 30, 2025 ceremony. The answer is yes. NIST CMVP records show two applicable validation certificates for this hardware series:
While both certificates transitioned to Historical status on September 21, 2026, as part of NIST’s industry-wide sunset of FIPS 140-2 in favor of FIPS 140-3, were actively Level 3 validated at the time of the key generation. Furthermore, both module validations included Cryptographic Algorithm Validation Program (CAVP) listings for ECDSA KeyGen (C119 and ECDSA 897), covering the P-384 algorithm in question.
However, hardware certification alone does not guarantee cryptographic assurance. FIPS 140-2 Level 3 compliance is strictly conditional on the module operating in its enforced FIPS mode. Were these private keys generated directly on the HSM board, or were they processed via an external wrap/unwrap script on a host machine and subsequently imported? In an enforced FIPS mode state, importing unvalidated key material without cryptographically bound entropy attestation is typically prohibited across vendors. This distinction raises critical technical questions that remain unanswered.
Baseline Requirements for CA/B Forum Members
Having established eMudhra's status as a full CA/Browser Forum member, it follows that their issuing operations were bound by the Forum's governance standards, and their own CP/CPS documents. Because the compromised ICAs were intended for TLS and Code Signing, they also fell directly under the purview of both the Server Cert Working Group and Code Signing Cert Working Group Baseline Requirements. Did eMudhra satisfy these baseline standards during execution? To answer that, we must examine the specific key generation requirements dictated by the Forum.
CA/B Forum Server Cert Working Group Audit Requirements
The Server Cert Working Group Baseline requirements applicable on April 30, 2025 eMudhra key signing ceremony was version 2.1.4.
Section 6.1.1.1 states the following:
'6.1.1.1 CA Key Pair Generation For CA Key Pairs that are either: i. used as a CA Key Pair for a Root Certificate or ii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL:
1. prepare and follow a Key Generation Script,
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and
3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.
For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD: 1. prepare and follow a Key Generation Script and 2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process. In all cases, the CA SHALL:
1. generate the CA Key Pair in a physically secured environment as described in the CA’s Certificate Policy and/or Certification Practice Statement;
2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA’s Certificate Policy and/or Certification Practice Statement;
4. log its CA Key Pair generation activities; and
5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.'
CA/B Forum Code Signing Cert Working Group Audit Requirements
The requirements in section 6.1.1.1 read the same in the Code Signing Cert Working group baseline requirements. Version 3.9.0 would have been the effective version at the time of the Key Signing Ceremonies.
**
Several critical questions remain at the time of writing: Does a video recording or official transcript of the Key Generation and Key Signing Ceremonies exist? If a recording exists, was the scope of review limited strictly to procedural checks, such as role separation, dual control, and physical security; or did the witness perform technical verification as well? Specifically, did anyone verify that the HSM firmware was FIPS-compliant and running in an enforced FIPS mode? Existing audit standards do not currently mandate these deeper technical verifications.
Based on industry experience, our working hypothesis is that WebTrust audits remain predominantly procedural, omitting the technical checks that could have mitigated eMudhra’s configuration error prior to issuance. We outline our proposal for addressing this systemic gap in our Recommendations section.
Audit Requirements
Based on eMudhra’s CP/CPS and the CA/B Forum Baseline Requirements, the private keys should have been generated inside a FIPS 140-2 or 140-3 Level 3 compliant HSM, identified in the Mozilla bug tracker by an eMudhra stakeholder as an Utimaco CryptoServer Se-Series Gen2. Yet our core technical question remains: was the FIPS-validated HSM actually generating the key pair directly, and was it actively operating in an enforced FIPS mode during execution?
This brings us to the role of the qualified auditor, whose mandate under the Baseline Requirements is to witness or verify the recording of Key Generation and Key Signing Ceremonies. The official WebTrust Assurance Report issued by BDO covered the period from June 1, 2024 through May 31, 2025. Working within the established WebTrust framework, this audit evaluated eMudhra under CP/CPS version 1.18 (effective March 14, 2025), encompassing the April 30, 2025 key generation event and including the eight impacted ICAs within its operational scope (as documented in the Mozilla bug tracker).
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
BDO’s engagement evaluated eMudhra against applicable CP/CPS revisions using the WebTrust Principles and Criteria for Certification Authorities - Version 2.2.2 ) as its audit baseline. Section 4.1 of this document covers the requirements for CA Key Generation:
Item c) states ‘generation of CA keys occur within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA’s CPS', and
item d) states 'generation of CA keys are witnessed by an independent party and/or videotaped’ - which aligns with the CA/B Forum baseline requirements.
The findings of this audit conclude:
‘In our opinion, throughout the period 1 June 2024 to 31 May 2025, emSign PKI management’s assertion, as referred to above, is fairly stated, in all material respects, in accordance with the Webtrust Principles and Criteria for Certification Authorities - Version 2.2.2.'
Furthermore, emSign PKI management’s assertion explicitly covers "CA Key Generation" as a CA service under its responsibility.
Because management’s assertion explicitly claims responsibility for CA Key Generation controls, fundamental questions arise: Was BDO the qualified auditor that witnessed the April 30, 2025 Key Generation Ceremony for the eight impacted ICAs, or was a video recording made? (As noted in our section on CA/B Forum Baseline Requirements, key ceremonies require either the physical presence of a qualified auditor or a complete video recording of the process.) Did the audit verify that the HSM was running FIPS-validated firmware in an enforced FIPS mode, and did anyone validate the entropy source?
It is important to emphasize that entropy source verification is not currently a requirement for qualified auditors under WebTrust 2.2.2, a gap we address in our Recommendations Section. While qualified auditors provide a critical check and balance, expanding audit mandates to include technical verification would serve as another important ecosystem guardrail. Furthermore, because commercial HSMs generate tamper-evident logs, providing these logs as part of eMudhra’s reporting obligations to the CA/B Forum would enable a full root-cause analysis of the poor entropy used to generate these key pairs.
Preliminary Analysis: Audit the Entropy Source
While primary responsibility and accountability rest with eMudhra for generating trivially recoverable ECDSA private keys, this incident highlights critical opportunities for ecosystem-wide improvement. These extend directly to the CA/Browser Forum Baseline Requirements and the auditing frameworks tasked with witnessing key generation and signing ceremonies.
Recommendations
Our first observation regarding the CA/B Forum Baseline Requirements focuses on Section 6.1.1.1, Item 2, which mandates that key generation be witnessed by a qualified auditor. Because this requirement was nominally met while still allowing a critical failure to manifest, it is evident that the definition of qualified needs sharpening. We recommend expanding the auditor's scope to include technical verification of HSM operations rather than relying solely on procedural witnessing. Verifying HSM firmware revisions and confirming active execution in an enforced, FIPS-compliant mode would provide technical assurance that the underlying entropy source is operating correctly thus preventing weak private keys from being generated in the first place.
Our second observation concerns ecosystem transparency. We recommend that video recordings of all CA/B Forum Root and Intermediate CA Key Generation and Signing Ceremonies be published openly for public review. Root store trust lists integrated into modern browsers protect billions of users worldwide; providing public visibility into these foundational events would build systemic trust and help prevent failures like the eMudhra incident. IANA serves as an excellent precedent here, they have publicly archived the operational procedures and full video recordings for every DNSSEC Root Key Signing Key Ceremonies since inception.
The Web PKI community is currently waiting for eMudhra to fulfill its disclosure obligations under CA/B Forum rules. This situation underscores why public ceremony recordings are so valuable: open video access allows immediate, objective verification by relying parties worldwide.
Significant technical questions remain regarding the Utimaco HSM's operational state and the transcripts and/or videos of the key generation ceremony.
While eMudhra faces intense public scrutiny and is opening the scrutiny to other stakeholders, much of the speculation stems from an information vacuum. Our interest is strictly analytical, if a public recording of the ceremony has been archived, the technical community could evaluate the facts directly rather than relying on guesswork.
Conclusion - It is not just the CA
Assigning blame is not our goal; driving continuous ecosystem improvement is. Achieving that requires three structural shifts: the CA/Browser Forum must refine and explicitly define the criteria for a ‘qualified auditor’; auditing bodies must expand their scope from procedural witnessing to include technical verification; and Certificate Authorities must embrace true transparency. When an entity serves as a trust anchor for millions or even billions of relying parties worldwide, public video archiving of key ceremonies should be the standard. The Web PKI landscape deserves nothing less.
At Innophia we have a team of experts focused on continuous improvement in the cryptographic landscape. Please contact us for any further guidance on any of the topics discussed in this blog.