The Number 4: A Cybersecurity Deep Dive into the eMudhra Certificate Authority Key Failure
The fact that the private key of “4” of a certificate authority is not a bug but rather a complete breakdown of the cryptographic assumption that lies behind every HTTPS padlock on the web.
On October 17, 2026, a researcher going by the name ‘Wayne’ informed both Mozilla and Google that eight intermediate certificate authorities run by the Indian CA eMudhra had private keys which were so weak that they could be recovered from public data in less than a second; one of the keys was actually the integer 4, while others were 56, 66, 115, 155, 156, 230, and 237; six of the eight were authorised to TLS certificates for websites and the other two were designated for code signing.
The major browsers and platforms had blocked the certificates within a few days and eMudhra announced within a week that it would be leaving the global SSL/TLS business altogether. This is the cybersecurity story of the single key generation ceremony that took place in April 2025, which produced keys with an effective security strength of three to eight bits, and of why the incident reveals flaws in audit, generation verification, and the trust model itself.
The Cryptographic Failure: When P-384 Becomes a Single Byte
An integer chosen from a space which is so large that brute-force recovery is impossible makes up a correctly generated NIST P-384 private key; the private key should be a random number consisting of dozens of digits and must be derived from a 384-bit keyspace. The public key is obtained by means of a mathematical calculation from the private key, and it is impossible to recover the private key from the public key when the appropriate values have been used, since this would require solving the elliptic curve discrete logarithm problem.
The eight eMudhra keys had not been properly selected since all of them were integers less than 256. This meant that there were 255 possible values for each of the effective keys. Instead of having to solve a discrete logarithm, an attacker could just generate the first 256 possible P-384 private keys, work out the corresponding public keys, and then compare them with the public certificate. Dennis Jackson of Mozilla confirmed that he was able to recover the keys “near instantly” by using the baby-step giant-step method or by simply generating the first 256 P-384 keys.
Scott Helme expressed the seriousness of the failure in simple terms by stating that one of eMudhra’s certificate authority private keys is the number 4. In a subsequent statement, he made it clear that it was not a number that started with 4 or the number 4 followed by a large number of random digits; it was simply 4. The private key associated with the certificate labelled “EM OV TLS CA — G3C” was the integer four, with leading zeros added to bring it up to the 384-bit format.
The security provided by these keys was between three and eight bits, depending on the value in question; modern TLS seeks to achieve at least 112 bits of security. The discrepancy between the level of protection intended and that which is actually achieved is not one of degree but rather the difference between a real lock and a picture of a lock.
How the Key Generation Ceremony Failed
The explanation given by eMudhra to Mozilla and afterwards made public attributes the failure to a key generation ceremony that took place on April 30, 2025. The company stated that a defect in either the wrap or the unwrap procedure caused the ceremony to generate a second batch of weak keys together with the desired strong keys. The weak keys were then issued to the browser root stores, whereas the strong keys were not.
Kaushik Srinivasan, who is one of the co-founders of the company, later identified the cause as a result of both a script error and a human error. He stated in an interview with the Times of India that because of the delays in obtaining the hardware for the North American operations the keys had to be generated in India and then exported; a script error led to the production of weak keys and the lack of effective maker-checker controls meant that the problem was not detected.
A key point in Mozilla’s investigation is that all of the affected keys were the P384 keys relating to two series (B and C) out of a batch of 24 intermediate certificates that had been generated that day. The A series, which had used different keys, was withdrawn and replaced in May 2025 for reasons that were unrelated to this issue. The P384 keys of the B and C series stayed in use.
A earlier warning sign had been ignored. In May 2025 eMudhra released certificate revocation lists concerning the affected intermediates whose signatures were invalid. Srinivasan admitted that when the signatures failed validation the team had used the weak keys. He agreed that a maker-checker procedure should have been followed at that time to find out what had gone wrong, and called the problem with signing the CRL a later mistake and probably an early warning sign.
The details about the weak keys were made public in April 2025 and remained undetected for about eighteen months. While it was undergoing this time frame the affected intermediates were subject to two separate audits. These audits failed to identify the fact that the keys were numerically trivial. This finding is important in itself since it shows that compliance with procedures and the review of documentation can certify a process which is generating cryptographically broken output even if the actual key material is not examined.
The Exposure Window and the Forgery Capability
The way in which a certificate authority extends trust to end-entity certificates is through the use of an intermediate CA private key. Should an attacker obtain that key, they would be able to sign certificates for any domain whose certificate chain leads to the intermediate, and any client that trusts the intermediate would regard the forged certificate as valid. This is what underlies website authentication. If the intermediate key is weak then the authentication guarantee ceases to hold for every client that continues to trust the chain.
The exposure period lasted about eighteen months, from April 2025 to October 2026. Throughout this period, anybody who looked at the public certificates was able to work out the private keys. The public key is shown in the certificate and, since the keyspace is 256, recovering it is straightforward. The issue of whether or not anyone in fact took advantage of the weakness is a separate matter from the question of whether the system was secure. The system was not.
Google said that there were no TLS certificates chaining to the six affected TLS intermediates listed in the Certificate Transparency logs prior to the blocking action. Certificate Transparency is a system which publicly records trusted TLS certificates; if no end-entity certificates had been issued by the affected intermediates and entered into the logs, then it meant that no fraudulent certificates had been issued via the normal public route. eMudhra also stated that none of the affected intermediate CAs, including the one that had been put into production, had issued any end-entity certificates.
It reduces the actual damage caused. It doesn’t lessen the proven failure of the trust model. The keys could be recovered and the ability to forge was present. The fact that nobody seems to have used it doesn’t alter the fact that the system was working on a false assumption for eighteen months.
The risk also went beyond browsers. Dennis Jackson from Mozilla pointed out that although major browsers make use of methods such as OneCRL, CRLite, and CRLSets to distribute revocation information, many other clients do not make use of that revocation information and instead have to rely on software updates in order to stop trusting the compromised intermediates. Scott Helme showed in a test environment that the default settings of curl, Python, and Node.js accepted forged certificates that were signed with the weak keys. Enterprise applications, payment gateways, vendor integrations, older Java applications, mobile apps, and network appliances might use certificate trust stores that are separate from those of browsers, and these situations would therefore require separate assessment and remediation.
The Browser and Platform Response
The browser vendors and platform operators reacted quickly, and that is the only aspect of this situation which functioned as intended.
Get GraySentinel- Cyber Defence Lab’s stories in your inbox
Join Medium for free to get updates from this writer.
Mozilla was given the report on October 17 at 20:06 UTC and, on its own, managed to recover the private keys by 21:48 UTC, verifying the vulnerability without having any knowledge of the reporter’s method. It then issued a revocation block via OneCRL, its centralized revocation list, to Firefox users who had standard configurations, without the need for them to update or restart their browser. Google Chrome provided an update to its Chrome Revocation List Set which blocked the affected intermediates, and Android and Chromebooks received the same update via Google Play Services. Apple added safeguards on October 19 and Microsoft finished implementing its block around October 20.
Google likewise took the emSign ECC Root CA — G3 certificate out of the Chrome Root Store, the change being scheduled to arrive on devices on October 27, and Mozilla removed the company’s root certificate from its list of trusted certificates.
V. Srinivasan, who is the Chairman, stated that eMudhra had cancelled the relevant certificate authorities within 14 hours of becoming aware of the issue. The company added that its infrastructure had not been compromised, no data had been breached, and both the physical and logical security measures had stayed intact. The containment process was quick and the failure had occurred upstream.
The Audits That Did Not Catch It
The fact that the weak keys managed to survive two separate audit cycles is one of the most important points about this incident from the standpoint of the cybersecurity community; an audit which looks at the processes, the documentation, and compliance with procedures might approve a key generation ceremony that resulted in the number 4 being used as a private key if that audit does not check the actual key material.
The audits were not the only instance in which a check had failed. The mistake made when signing the CRL in May 2025 was an indication that there was a problem with the key configuration. The team used the wrong key to sign the CRLs, the signatures then failed, and rather than investigating the discrepancy between the keys they instead used the weak key. The maker-checker control which should have picked up the discrepancy was not applied.
When Kaushik Srinivasan was asked why the problem had not been detected for eighteen months, he stated that he did not know, mentioning that the company had audit and disclosure procedures. The independent review which eMudhra has committed to having carried out will have to consider the fact that the audit process had not picked up keys with three to eight bits of effective security.
The main point is that in order to generate keys it is necessary to carry out output verification, not merely follow the prescribed procedures. If a ceremony produces a strong key and a weak key and yet publishes the wrong one, then there is a procedural failure, but the more fundamental failure is that there was no check carried out on the entropy and the value range of the generated key. A key with the value 4 would fail any reasonable output test. The fact that it had passed two audits indicates that the checks were not designed to examine the output.
The Exit and the Structural Pressures
On October 22, 2026, eMudhra announced its decision to leave the global SSL/TLS business since its shares had triggered the circuit breaker for two successive trading sessions and had lost over a third of their market value within 48 hours. Although the global SSL/TLS business contributed less than one percent to the company’s revenue, the reputational harm suffered was disproportionate.
The company pointed to three structural pressures in addition to the incident: increasing compliance costs, data sovereignty requirements, and decreasing commercial returns. The rules relating to data sovereignty and compliance have made the business more complicated and expensive to operate. The availability of free certificate providers has reduced margins. The shorter validity periods of certificates add to the operational burden.
The exit has no impact on eMudhra’s other business activities. It is reported that operations in the area of digital signature certificates, eSign services, enterprise PKI platforms, and identity authentication products are carrying on as normal and are therefore not affected. In the case of existing SSL/TLS customers, the company is transferring them to partner providers at no cost, the G1 RSA root continuing to serve during the transition and revocation and certificate status services remaining in operation until all the certificates have expired or have been replaced.
The situation has also attracted the attention of Indian authorities, who have formed a committee to investigate the incident, while CERT-In published an advisory saying that eight of the eMudhra intermediate certificate authorities had been affected by a flaw in key generation which led to the creation of weak cryptographic private keys.
What This Incident Teaches About Trust Infrastructure
The eMudhra incident is not an example of a skilled attacker overcoming robust defences. It is rather a case of a key-generation process having produced keys that were so weak that defence against them was unnecessary. The attacker, who in this instance was a security researcher, did not break cryptography; instead, he realised that cryptography had not in fact been applied.
The following lessons apply to anyone who uses or relies on certificate authority infrastructure.
It is essential that key generation checks its output; if a ceremony produces both a strong key and a weak key and then publishes the wrong one, this is a failure of the process, but it only becomes a security failure because no check had picked out the weak key before it was published. The verification of the output, including the assessment of entropy and the validation of the value range, must not be optional.
Audits should examine the actual material, not just the procedures. Two separate audits approved a process which produced a key of 4. An audit system that neither samples nor checks the real cryptographic values is able to give certification to a flawed process. It was precisely in the gap between adherence to procedure and cryptographic soundness that this case remained for eighteen months.
Warning signs should be looked into, not just dealt with by workarounds. The fact that the CRL signing failed in May 2025 was an indication that the key configuration was not the one that the team had expected. Instead of investigating why the original key had failed, they chose to sign using the weak key. At that time, a maker-checker process could have detected the generation flaw eleven months before its public disclosure.
The revocation infrastructure does work, but only when it is used by clients. The major browsers had secured their users within a few hours. However, enterprise applications, command-line tools, and embedded devices that either do not check revocation or have their own separate trust stores continued to be at risk until they were patched. This event serves as a reminder that security for browsers is not equivalent to system security.
A minor part of the business can involve excessive trust risk. Although the global SSL/TLS business accounted for one percent of revenue, it was a certificate authority function that enjoyed public trust. The reputational damage resulting from a failure in that function is not proportional to its contribution to revenue. The fact that the board had calculated that exiting was more advantageous than carrying out remediation shows this imbalance.
The situation resulting from the eMudhra incident ended in a fairly harmless way: there was no sign of malicious exploitation, no end-entity certificates were issued by the affected intermediates, and the problem was quickly contained. Yet the fundamental failure — a private key of a certificate authority that ranked number 4 — serves as a reminder that the trust system of the web is based on the idea that the numbers involved are not easily guessable. Once that assumption is broken, the failure is not slow; it is complete.
