Category: Cybersecurity & PKI Infrastructure
Every time a user connects to an encrypted website, their system places complete confidence in the global Public Key Infrastructure. Behind that connection sit Certificate Authorities, whose private cryptographic keys authenticate digital identities across the internet. Under the elliptic curve standard NIST P-384, a private key is designed to be an astronomically large 384-bit random number chosen from a pool 116 digits long. Brute-forcing such a key is mathematically impossible.
What happens, however, when the secret number guarding a publicly trusted Certificate Authority is not 116 digits long, but is simply the number 4?
In October 2026, the cybersecurity community discovered that eight publicly trusted Intermediate CA certificates operated by eMudhra (under its global emSign brand) carried a catastrophic Weak Key Pair flaw. No servers were breached, and no physical hardware was compromised. Instead, an unverified script deviation during a key generation ceremony, a botched wrap/unwrap key routine inside a Hardware Security Module (HSM), and a misdiagnosed Certificate Revocation List (CRL) signature failure left eight Intermediate CAs vulnerable to instant derivation for nearly 18 months.
The Architecture: HSMs, Key Wrapping, and DC/DR Replication
Certificate Authorities do not store private keys on standard server drives. Instead, keys are generated and stored inside a Hardware Security Module (HSM)—a tamper-resistant, FIPS 140-2 Level 3 certified cryptographic device designed to prevent plaintext key extraction.
To back up keys from a primary Data Center (DC) to a Disaster Recovery (DR) site, or to export them to regional data centers for local compliance and high availability, CAs rely on a cryptographic mechanism known as key wrapping and unwrapping (C_WrapKey and C_UnwrapKey). During a wrap step, the source HSM encrypts the private key under a transport key before exporting it. At the destination HSM in another DC or DR facility, the unwrap step decrypts and imports the key directly into the secure hardware boundary.
When properly implemented, key wrapping preserves both secrecy and cryptographic integrity across DC and DR environments. When modified and executed in a live production environment without independent validation, it introduces severe risks.
April 30, 2025: The Key Generation Ceremony and the Wrap/Unwrap Flaw
On April 30, 2025, eMudhra conducted a formal Key Generation Ceremony to generate 24 new subordinate CAs. Domestic Indian CAs (Series A) were generated on Entrust HSMs and remained secure. However, Series B and C intermediates were generated on Utimaco Se-Series Gen2 HSMs, intended for export to eMudhra’s European and United States Data Center (DC) environments.
During the ceremony, an approved deviation was introduced into the automation script to test key wrap and unwrap procedures for overseas DC deployment. This procedure triggered a critical failure chain:
- Onboard Key Generation: The Utimaco HSM generated the original P-384 key pairs onboard with full 384-bit cryptographic entropy.
- The Wrap/Unwrap Routine: The script wrapped, unwrapped, and re-imported the keys back into the HSM as part of an operational test.
- Creation of the Weak Key Pair: A software defect in the script corrupted the private scalar data during re-import. Instead of 48 random bytes, the re-imported private keys consisted of 47 zero bytes followed by a single byte. The resulting key scalar (d) size was reduced from 384 bits of entropy to an 8-bit integer between 1 and 255. One private key scalar was literally 4; the remaining seven were 56, 66, 115, 155, 156, 230, and 237.
- Key Label Collision: The HSM assigned near-identical labels to both the original strong key objects and the re-imported weak key objects. Because the script selected keys by label rather than by cryptographic public-key fingerprint, the Certificate Signing Requests (CSRs) were built using the re-imported Weak Key Pair handles.
On May 10, 2025, the intermediate certificates were published to the Common CA Database. On May 14, 2025, Sectigo cross-signed the same CSRs under its legacy AAA Certificate Services root, extending the vulnerable keys across 16 publicly trusted certificates.
The Ignored Warning: CRL Signature and Distribution Failures
The cryptographic ecosystem provided an early warning less than a month later, but the alert was misdiagnosed.
Between May 23 and May 29, 2025, eMudhra published its initial Certificate Revocation Lists (CRLs) for the six TLS intermediates. Automated monitors immediately flagged that all six CRLs had invalid ECDSA signatures.
The cause was clear:
- eMudhra’s CRL signing application was pointed to the original, strong private key handles in the HSM.
- The published CA certificates in the wild contained the public keys of the re-imported Weak Key Pair.
- Because the key signing the CRL did not match the public key in the certificate, signature verification failed.
Sectigo reported the mismatch on June 3, 2025, though the email was temporarily quarantined by internal spam filters. When eMudhra investigated on June 6, 2025, the team had evidence that two conflicting key pairs existed for each CA. Instead of halting operations and auditing the key generation ceremony, the issue was treated as a routine configuration mismatch. eMudhra reconfigured the CRL software to point to the re-imported weak key handles and re-signed the CRLs.
Because the weak private keys matched the weak certificates, the signatures verified cleanly. This change silenced the warning and left the vulnerable certificates active for another 16 months.
Operational problems with CRL distribution recurred on October 14, 2026. While remediating an invalid CRL Distribution Points extension in OCSP certificates, an operator key-mapping mistake caused the Root CRL for emSign Root TLS CA – G1 (CRL #11) to be signed using a delegated OCSP responder private key rather than the Root CA key.
October 17, 2026: Discovery and Derivation
On October 17, 2026, an independent security researcher tested the public CA database using Google’s open-source paranoid_crypto scanning tool. Within 27 minutes, the tool flagged all eight eMudhra P-384 intermediates.
Because every private key scalar was an integer below 256, deriving the private keys required no advanced cryptanalysis. A researcher only needed to compute points 1 through 255 on the curve until matching the public key. The researcher verified all eight private keys, signed an attestation statement, and alerted major root programs (Google Chrome, Mozilla, Apple, Microsoft) and eMudhra.
Mozilla cryptography engineers independently recovered all eight keys within two hours, confirming that automated scripts and local AI tools could recover them on the first attempt. Security researchers demonstrated full key derivation on standard laptops in fractions of a second.
Consequences: Ecosystem Disruption and Market Exit
The exposure of eight intermediate private keys—six for TLS and two for Windows Authenticode code signing—triggered an emergency industry-wide remediation.
1. Why Systems Remained Vulnerable
Major web browsers blocked the compromised keys rapidly: Google Chrome deployed a public-key block via CRLSet within 100 minutes, and Mozilla deployed a OneCRL block within hours. Because modern browsers enforce Certificate Transparency (CT), an attacker could not present an unlogged fraudulent certificate to browser users without detection.
However, non-browser infrastructure remained vulnerable:
- Backend Runtimes and Containers: Runtimes such as Go, Python (certifi), Node.js, and Java do not enforce Certificate Transparency and rarely perform live CRL or OCSP checks by default. An attacker intercepting traffic could use the derived keys to issue forged certificates for any domain, and unpatched backend services would accept them. The Go security team issued emergency releases (CVE-2026-111943) hard-coding a blocklist of the eight public keys into the standard library.
- Code Signing Risks: The two compromised code-signing intermediates allowed arbitrary binaries and malware to be signed with valid Authenticode signatures, bypassing Windows security warnings until Microsoft updated its Disallowed Certificate list on October 20.
- The Cross-Signing Multiplier: Because Sectigo had cross-signed the weak keys under its 2004 AAA Certificate Services root, legacy devices and embedded systems that did not even include eMudhra’s roots were exposed to forged chains.
2. Root Eviction and Subscriber Disruption
Because standard CRL distribution does not reliably protect non-browser clients, Mozilla and Google removed the parent root certificate, emSign ECC Root CA – G3, from their root stores.
Although the eight compromised intermediates had not issued public end-entity certificates, removing their parent ECC root disrupted legitimate intermediate CAs sharing that hierarchy. Approximately 30,800 unexpired certificates—predominantly serving US educational and research institutions under the Internet2 / InCommon federation—lost browser trust and required emergency migration to eMudhra’s RSA hierarchy or alternative providers.
3. Regulatory Inquiries and Exit from Global TLS
India’s Ministry of Electronics and Information Technology (MeitY) formed an investigation team, while CERT-In issued a national security advisory confirming that eMudhra’s domestic digital signature (DSC) and eSign infrastructure runs on separate hardware and was not impacted.
Following consecutive 20% drops in its share price on Indian exchanges, eMudhra announced on October 22, 2026, that it would permanently exit the global public SSL/TLS certificate business. The company confirmed it will wind down public TLS issuance, assist subscribers with transition pathways, and refocus on its enterprise and domestic identity solutions.
Key Engineering Takeaways
The eMudhra incident demonstrates that compliance certifications do not eliminate operational risk:
- Isolate Test Routines from Production: Key wrap and unwrap procedures intended for DC/DR replication or data center export must be tested on dedicated lab partitions, never during live production key generation ceremonies.
- Bind Keys by Cryptographic Fingerprint: Selecting HSM key objects by text labels creates single points of human failure. Workflows must bind keys by the cryptographic hash of their public key (SPKI) and verify hardware generation attributes (CKA_LOCAL).
- Automate Public Key Hygiene: Simple checks for small scalars and low entropy take milliseconds to execute and should be mandatory gates before any CSR is signed or submitted to root stores.
- Investigate Signature Failures Thoroughly: When a CRL signature fails verification against a live certificate, the discrepancy must be treated as a critical anomaly rather than a formatting glitch. Addressing the underlying cause prevents catastrophic vulnerabilities from hiding in plain sight.