NEW YORK — The internet's trust system, built on layers of complex cryptography, was recently shaken by an extraordinary revelation: one of the private keys meant to secure countless websites was reportedly the number 4. This catastrophic flaw, originating from India's eMudhra certificate authority, exposed a fundamental weakness in the digital infrastructure underpinning HTTPS, prompting urgent action from major browser vendors and raising profound questions about the security of the Web Public Key Infrastructure.
On October 17, 2026, a security researcher identified only as "Wayne" reported a critical vulnerability concerning eight intermediate Certificate Authority (CA) private keys operated by eMudhra, an Indian digital trust services provider. These private keys were found to be catastrophically weak due to insufficient randomness during their generation in April 2025. Crucially, one of these private keys was reportedly the number 4, while others were also extremely small, with values less than 256. This weakness meant that the private keys could be easily derived from their corresponding public certificates. Six of the compromised intermediates were for TLS (website security) certificates, and two were for Microsoft-trusted code-signing certificates.
To understand the gravity of this, it is important to grasp the role of a Certificate Authority. A CA is a trusted organization that issues digital certificates, which are essential for verifying the identity of websites, users, and applications. CAs act as a trusted third party, confirming that a public key belongs to the entity requesting the certificate, thereby establishing trust in digital communications. This system is fundamental to Public Key Infrastructure (PKI) and secures billions of daily digital interactions, including the HTTPS encryption for websites.
An intermediate CA, like those compromised at eMudhra, is a subordinate Certificate Authority signed by a superior CA, such as a Root CA. Its primary role is to issue certificates to end entities, like websites, on behalf of the Root CA, thereby protecting the highly sensitive Root CA's private key from direct exposure. Intermediate CAs form a "chain of trust" from the end-entity certificate back to a trusted Root CA embedded in browsers and operating systems.
At the heart of this system is the private key. In public-key cryptography, a private key is a confidential cryptographic value mathematically paired with a public key. While the public key can be widely shared, the private key must remain secret and is held only by its owner. It is used for crucial functions such as decrypting messages and creating digital signatures to verify identity and ensure data integrity.
Elliptic Curve Cryptography (ECC) P-384, the algorithm used for these keys, is designed to generate private keys that are extremely large, random numbers. For a properly generated P-384 key, the range of possible values is enormous, roughly 10^115 possibilities. This vast number makes it computationally infeasible for an attacker to guess or "brute-force" the private key, even with immense computing power, ensuring the security of the cryptographic system.
The value 4, or any other extremely small number, was catastrophically weak because it lacked sufficient cryptographic randomness, or "entropy." Instead of being large, random numbers, these keys had extremely small values, all reportedly less than 256. A security researcher demonstrated that all eight keys could be recovered in under a second by simply testing a maximum of 256 possible values. This was not a "crack" of the P-384 algorithm itself, but rather a severe implementation failure in eMudhra's key generation process. The small values meant that the mathematical difficulty designed into the P-384 curve was entirely bypassed.
Theoretically, an attacker who obtained these weak private keys could have used them to forge trusted HTTPS certificates for any domain. Since these intermediate CAs chain to roots trusted by major browsers and operating systems, such forged certificates would appear legitimate to clients that still trusted the compromised CAs. This would enable attackers to impersonate legitimate websites, conduct "man-in-the-middle" attacks, intercept encrypted traffic, and potentially modify data without detection. The two compromised code-signing keys could also have been used to sign malicious software, making it appear as if it came from a trusted publisher.
However, as of the latest reporting, there is no evidence that attackers actually exploited these weak keys or that any data breaches occurred as a result of the incident. Google's Chrome Root Program reported that no TLS certificates chaining to these six intermediate CAs were logged to Certificate Transparency (CT) before their blocking action. Chrome, by default, enforces CT for all publicly trusted certificates, which would have exposed any fraudulently issued certificates. eMudhra also stated that none of the affected intermediate CAs had issued any end-entity certificates to individual websites or end users. India's Computer Emergency Response Team (CERT-In) also stated it had not seen any malicious use of the keys.
Major browser vendors and operating system providers acted swiftly upon receiving the report. Google's Chrome Root Program corroborated the findings within hours and deployed a CRLSet update that blocked the Subject Public Key Info (SPKI) hashes of the affected intermediate CAs. This method immediately protected Chrome users against all certificates sharing those keys without requiring a browser update or restart. Android devices and Googlebooks received equivalent updates through Google Play Services. Mozilla emergency-distrusted eMudhra's emSign ECC Root CA - G3. Apple and Microsoft also followed with their own blocking actions within days. eMudhra itself revoked all eight compromised intermediate certificates on October 18, 2026.
The critical question remains: how could such a fundamental problem survive for roughly 18 months and pass audits? The weak keys were generated in April 2025 and remained undetected despite the affected certificate authorities having undergone two consecutive years of independent audits and being included in browser trust lists since mid-2025. eMudhra attributed the issue to an error in a script used during a key generation ceremony in April 2025. This faulty script, during a "wrap/unwrap" step, produced a second set of weak keys alongside the intended strong keys. Due to similar labels, staff mistakenly selected and published the weak keys when preparing the certificates. An earlier warning sign in June 2025, where Mozilla recorded invalid certificate revocation list (CRL) signatures from the same six TLS intermediates, was misdiagnosed by eMudhra as a manual process error, and they simply re-signed the lists with the weak keys instead of investigating the underlying cause. This suggests a failure in both the automated key generation process and the subsequent auditing and incident response procedures.
This eMudhra incident reveals several critical insights about the Web Public Key Infrastructure and the security of HTTPS. Firstly, it underscores that the strength of cryptographic algorithms like P-384 is only as good as their implementation. A fundamental flaw in key generation, even if the algorithm itself is robust, can completely undermine the entire system. Secondly, it highlights the limitations of audits, as this severe vulnerability persisted for 18 months despite independent reviews. Thirdly, the incident exposed a significant disparity in how different clients handle certificate trust. While modern browsers quickly blocked the compromised certificates using mechanisms like CRLSets and Certificate Transparency enforcement, many non-browser environments—such as operating systems, language runtimes, containers, embedded systems, and IoT devices—often do not check revocation data or CT logs. These systems require explicit software updates to remove trust in the compromised keys, leaving a prolonged exposure window for potentially vulnerable applications. This incident serves as a stark reminder that certificate security relies not just on strong encryption, but also on secure key generation, robust validation, timely revocation, and consistent trust-store updates across the entire digital ecosystem.
Following the incident, eMudhra's board decided to voluntarily withdraw from its global SSL/TLS certificate business. Chairman V. Srinivasan stated that the global SSL/TLS business contributed only about 1% of eMudhra's global revenue. He also highlighted increasing complexity and costs associated with data sovereignty and compliance requirements, as well as competition from large providers offering free certificates, which reduced the business's commercial viability and return on investment. Srinivasan further noted that the "social media amplification" around the incident brought "scrutiny that is out of proportion to SSL/TLS's place in our business." eMudhra announced it would replace affected customers' certificates with free ones from partners, such as Sectigo, and would continue operating revocation and certificate status services until all issued certificates expire or are replaced. The company clarified that its Indian digital signature certificate (DSC) and eSign businesses, which run on separate infrastructure, remain unaffected.
How can an internet built on extremely strong cryptography be undermined by something as basic as a badly generated number? The eMudhra incident provides a stark answer: the most sophisticated cryptographic algorithms are only as secure as their weakest link in implementation. The system relies on a chain of trust, and a single, fundamental error in generating a private key—the very foundation of that trust—can theoretically unravel the security for millions. It is a powerful reminder that robust security demands not just advanced mathematics, but also meticulous engineering, vigilant auditing, and rapid, coordinated responses across the entire digital ecosystem.