One of the private keys protecting part of the global HTTPS trust system was, according to a report from The Register published October 20, 2026, the number 4. Not a 384-bit cryptographic value. Just the digit 4.
The key belonged to Indian certification authority eMudhra, specifically to an intermediate certificate called EM OV TLS CA – G3C. It was one of eight intermediate CA certificates that eMudhra has now confirmed carried guessable private keys, a flaw serious enough to let an attacker who found the pattern forge HTTPS certificates for sites that browsers and operating systems were built to trust. The eMudhra private key compromise is now working its way through the web’s certificate-revocation machinery, and it is forcing a hard look at how certificate authorities actually run their key-generation ceremonies.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What The Register’s Report Revealed About eMudhra’s CA Keys
The Register’s story framed the eMudhra private key compromise around a detail that is almost comic in a field obsessed with entropy: a certificate authority trusted by browsers worldwide had issued an intermediate certificate whose private key was the single digit 4. The outlet tied the finding to eMudhra’s global TLS certificate business, which operates separately from the company’s well-known India-focused digital signature and eSign services. Multiple outlets picked up the story within hours, including Hardware Busters, which detailed how eight certificates in total were affected, not just the one carrying the key “4.”
What makes the story land is the gap between expectation and reality. These are P-384 elliptic-curve keys, a format chosen specifically because it is supposed to deliver 384 bits of randomness, a number so large that guessing a correct value by brute force is considered computationally impossible with any hardware that exists today. Instead, at least eight of them turned out to be trivially small integers.
Eight Intermediate Certificates, One Private Key Was Simply “4”
According to reporting on the disclosure, the eight affected private keys carried the values 4, 56, 66, 115, 155, 156, 230, and 237. Every one of them is small enough to write on a sticky note, let alone recover computationally. The certificate tied to the value 4, EM OV TLS CA – G3C, is the only one of the eight that reports have named specifically.
A P-384 private key is supposed to be an essentially random number drawn from an astronomically large range. When that number instead turns out to be single-digit or triple-digit, the private key is not really private anymore. Anyone who downloads the corresponding public certificate, which is by definition public, can test small integer values against it until one matches. For a key like 4, that check takes a fraction of a second on an ordinary laptop.
How P-384 Keys With 384 Bits of Randomness Became Guessable
eMudhra’s own account of the root cause points to a malfunction in the key-generation ceremony itself rather than a hack or an external intrusion. In a statement, the company said a flaw in the key-generation process caused a wrap and unwrap step to produce a second set of weak keys alongside the original, properly generated strong keys. In effect, the ceremony that was supposed to produce one set of unguessable 384-bit values appears to have also spat out a shadow set of near-trivial ones, and the weak set is what ended up embedded in the eight affected certificates.
That distinction matters for how the industry responds. A stolen key implies an intrusion that needs to be hunted down and contained. A malformed key implies a process failure that needs to be audited and fixed at the ceremony level, which is exactly the posture eMudhra has taken publicly. The company has not described the incident as a breach of its systems, and no outlet covering the eMudhra private key compromise has presented evidence of external access to eMudhra’s signing infrastructure.
Timeline: From the April 2025 Ceremony to the October 2026 Disclosure
The affected keys trace back to a key-generation ceremony that reports place in April 2025, with one account specifying April 30, 2025, as the exact date. That means the weak keys sat embedded in live intermediate certificates for roughly a year and a half before anyone outside eMudhra flagged them publicly.
The disclosure moved fast once it started. Mozilla, which maintains one of the root certificate programs that browsers rely on to decide which certificate authorities to trust, logged a report on October 17, 2026, at 20:06 UTC concerning the eight intermediate certificates. Within days, the story had spread to outlets across multiple countries, including coverage from The Daily Pioneer, which described a global cleanup effort now underway across the browser and certificate authority ecosystem.
Scott Helme’s Discovery and the Mozilla Report
The researcher credited with surfacing the flaw is Scott Helme, a security researcher known for work on web security tooling. Reports say Helme found that one of the private keys was the number 4 and recovered it from a public certificate in under a second, a detail that turned a dry disclosure about P-384 entropy into a story simple enough for anyone to grasp immediately. Helme’s finding is what reached Mozilla’s certificate transparency reporting channel and triggered the formal revocation process.
Certificate transparency logs exist precisely so that research like this is possible. Every publicly trusted certificate gets logged, which means anyone, researcher or attacker, can scan the record for anomalies. In this case that transparency worked in the defenders’ favor. It is the same logging infrastructure that underpins modern browser trust decisions, the kind of plumbing that rarely makes headlines until something like the eMudhra private key compromise puts it to work.
eMudhra’s Official Response to the Weak Key Disclosure
eMudhra moved to contain the story on two fronts: narrowing the technical scope and separating its global TLS business from its core Indian operations. On scope, the company said the incident is limited to these specific intermediate CA certificates and does not affect eMudhra’s root CA private keys or other intermediate CAs, and added that none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. That second point is important: if accurate, it means no live website certificate was ever actually signed with one of the weak keys, which would narrow the real-world exposure considerably even though the keys themselves were exposed.
On the broader question of whether eMudhra itself was compromised, the company has been direct. In a statement addressing its security posture, eMudhra said all physical and logical security controls remained intact, framing the episode as a key-generation defect rather than an intrusion. eMudhra’s published statement on the matter lays out that position in detail for customers and relying parties who need to assess their own exposure.
What a Stolen CA Key Can Actually Do to HTTPS Trust
To understand why eight weak keys became international news, it helps to understand what an intermediate CA key is for. A certificate authority’s root key signs intermediate keys, and intermediate keys sign the certificates that browsers check when a user loads a website over HTTPS. If someone outside the CA holds a valid intermediate private key, they can, in theory, mint a certificate for any domain name they choose, and software that trusts the CA’s root will accept it without complaint. That is the mechanism reports point to when describing the risk: possession of an affected key could allow creation of fraudulent HTTPS certificates for websites trusted by software that accepts the relevant eMudhra CA.
That is a theoretical capability, not a confirmed attack. No outlet covering the story has produced public evidence that the weak keys were ever used to issue a fraudulent certificate or to intercept real traffic. The risk the eMudhra private key compromise represents is about what was possible for roughly eighteen months, not about a documented breach of any specific website’s traffic.
Revocation and Remediation: What’s Been Fixed So Far
Remediation has followed the standard WebPKI playbook. Reports confirm the eight certificates were revoked, and eMudhra stopped issuing under the affected root, cutting off any further use of the flawed key-generation path. That is the industry’s blunt instrument for this kind of problem: pull the certificates, cut the issuance chain, and let the browser root programs track compliance from there.
What happens next is largely procedural but not trivial. Root program operators at the major browser vendors typically open an incident bug, request a full postmortem from the certificate authority, and may impose restrictions on future issuance until they are satisfied the underlying ceremony process has been fixed. eMudhra’s public framing, that the issue was a process defect in one ceremony rather than a systemic security failure, will shape how quickly root programs decide the matter is closed.
Market Reaction and What’s at Stake for eMudhra’s Business
eMudhra has worked quickly to ring-fence the reputational damage to its core business. The company has stressed that India’s digital-signature-certificate and eSign services were unaffected, pointing out that the relevant global TLS infrastructure is separate from the systems Indian businesses and government bodies rely on for digital signatures. Moneycontrol reported on that distinction directly, noting eMudhra’s position that the global TLS business runs on infrastructure that is completely separate from the India DSC business.
That separation matters commercially. eMudhra’s digital signature and eSign products serve a large base of Indian enterprise and government customers, a business line with little direct overlap with its smaller global TLS certificate issuance arm. Whether the market treats the two as cleanly separable, or whether the eMudhra private key compromise drags on the company’s broader credibility as a trust-services provider, will likely play out over the coming weeks as customers and partners ask follow-up questions.
Historical Context: When Certificate Authorities Lose Trust
Certificate authorities occupy an unusual place in the security of the web. Browsers extend blanket trust to a short list of root programs, and any failure inside that list ripples out to every site that relied on the affected CA. The WebPKI’s history includes several episodes where a certificate authority’s practices came under enough scrutiny that major browsers eventually withdrew trust entirely, a process that typically takes months of public review before root programs act. Those past episodes are part of why Mozilla, Google, and Apple all run formal incident-reporting processes rather than handling CA problems informally.
Measured against that backdrop, the eMudhra private key compromise looks more contained than a full root-program distrust event, assuming eMudhra’s account holds up to scrutiny. Eight intermediate certificates with no confirmed misissuance is a different category of problem than a root compromise or years of undisclosed mis-issuance. But the comparison is exactly why root programs will want their own independent verification before closing the file.
How eMudhra’s CA Business Compares to Other Global Certificate Authorities
eMudhra sits alongside a handful of other publicly trusted certificate authorities that browsers and operating systems rely on by default, a group that includes names like DigiCert, Sectigo, and GlobalSign. All of them run the same basic process at the center of this story: a key-generation ceremony, typically performed in a controlled physical environment with multiple witnesses and audited scripts, that is supposed to guarantee the randomness of every private key a CA ever issues. The entire WebPKI trust model rests on the assumption that this ceremony step cannot fail quietly.
What sets the eMudhra private key compromise apart from a typical CA security story is where the failure happened. This was not a leaked key, a misconfigured server, or a social-engineering attack against CA staff, the categories that have caused the most publicized incidents at other certificate authorities over the years. It was a defect inside the cryptographic tooling used during the ceremony itself, a failure mode that every CA running similar hardware security modules and ceremony scripts now has reason to double-check.
eMudhra Incident at a Glance
| Detail | Reported Figure |
|---|---|
| Affected intermediate CA certificates | 8 |
| Key type | P-384 elliptic curve |
| Expected key strength | 384 bits of randomness |
| Key-generation ceremony date | April 2025 (one report cites April 30, 2025) |
| Mozilla report received | October 17, 2026, 20:06 UTC |
| Named affected certificate | EM OV TLS CA – G3C (key value: 4) |
| Root CA keys affected | No, per eMudhra’s statement |
| Remediation status | All eight certificates revoked |
The Eight Affected Intermediate Certificates and Their Reported Key Values
Reports converge on a specific list of integer values recovered from the eight weak keys. The table below lists each reported value in the order most commonly cited.
| Certificate Reference | Reported Private Key Value |
|---|---|
| EM OV TLS CA – G3C | 4 |
| Intermediate CA #2 | 56 |
| Intermediate CA #3 | 66 |
| Intermediate CA #4 | 115 |
| Intermediate CA #5 | 155 |
| Intermediate CA #6 | 156 |
| Intermediate CA #7 | 230 |
| Intermediate CA #8 | 237 |
Reports have not published which specific intermediate certificate corresponds to each of the remaining seven values beyond EM OV TLS CA – G3C, so the table above labels them generically by position. What is consistent across every account of the eMudhra private key compromise is that all eight values are small enough to be guessed by brute force in a trivial amount of time, nowhere close to the 384 bits of randomness the key format is designed to provide.
What Developers and Site Operators Should Check Now
For most engineering teams, the practical response to the eMudhra private key compromise is a checklist rather than an emergency. Sites that never used an eMudhra-issued certificate have nothing to do. Teams that are unsure should verify which CA actually issued their certificate chain, since certificate transparency logs make that lookup straightforward.
- Check your certificate chain’s issuing CA and confirm whether it traces back to one of the eight revoked eMudhra intermediates.
- Monitor certificate transparency logs for your own domains, the same mechanism that helped surface this incident in the first place.
- Treat hardware-backed key ceremonies as auditable processes, not black boxes, when evaluating any CA or signing vendor.
- Pair CA-issued TLS trust with phishing-resistant authentication wherever possible, since certificate trust is only one layer of web security.
That last point is where the story connects to a broader shift already underway in web authentication. Teams hardening their own infrastructure after a CA-level scare like this are often the same teams rolling out WebAuthn passkeys or deploying hardware security keys for their own internal systems, on the logic that reducing reliance on any single trust anchor, CA included, is a reasonable long-term posture.
Predictions: Where the eMudhra Fallout Goes From Here
A handful of outcomes look likely as the eMudhra private key compromise moves from breaking news to a closed incident report.
- Browser root programs will almost certainly require eMudhra to publish a full technical postmortem of the key-generation ceremony before resuming normal issuance oversight.
- Other certificate authorities using similar hardware security module tooling will quietly audit their own ceremony scripts for the same wrap and unwrap defect eMudhra described.
- Expect renewed industry debate about mandatory post-ceremony entropy testing, checking generated keys against known weak values before a CA ever puts them into production.
- eMudhra’s India-focused digital signature business will likely continue operating without interruption, but the company’s global TLS issuance volume may shrink while customers reassess.
- Security researchers will keep scanning certificate transparency logs for similar anomalies at other CAs, since this incident demonstrated how fast a single researcher can turn public log data into a major disclosure.
Why This Story Resonates Beyond Cryptography Specialists
Most certificate authority incidents stay inside specialist mailing lists. This one broke out because the central fact is legible to anyone, technical or not: a system designed to be unguessable turned out to include a key that was just the number 4. That simplicity is doing a lot of work in how the eMudhra private key compromise is being discussed outside security circles, including in consumer-facing coverage from India Today aimed at everyday internet users rather than engineers.
It also lands at a moment when CA-level failures are getting more scrutiny generally, alongside a steady drumbeat of other 2026 disclosures covering everything from a BeyondTrust zero-day to a critical Nextcloud flaw. Each of these stories chips away at the assumption that foundational infrastructure, the stuff most people never think about, is automatically solid.
The Bigger Pattern: Infrastructure Failures Behind the Scenes
The eMudhra private key compromise joins a run of 2026 incidents where the weak point was not a careless user but a process failure deep inside trusted infrastructure. The same month brought reports of a ConnectWise cloud backup breach affecting 173 tenants and a broader 53% year-over-year rise in ransomware attacks, both signs that attackers and researchers alike are probing the supply chain layer rather than individual endpoints.
For eMudhra specifically, the distinction between a process defect and a true breach is likely to define how the story is remembered. The company’s statement that all physical and logical security controls remained intact is the core of its defense, and it is a defense that root program operators and independent researchers will now spend weeks testing rather than simply accepting.
Frequently Asked Questions
What is the eMudhra private key compromise?
It is the disclosure that eight of eMudhra’s intermediate certificate authority certificates carried guessable private keys, including one certificate whose key was the single value 4, rather than a properly randomized 384-bit P-384 key.
Was eMudhra’s root certificate authority key affected?
No. eMudhra has stated the incident is limited to eight specific intermediate CA certificates and does not affect its root CA private keys or any other intermediate CAs.
Who discovered the weak eMudhra keys?
Security researcher Scott Helme is credited with reporting that one of the private keys was the number 4 and recovering it from a public certificate in under a second.
Were any fraudulent HTTPS certificates actually issued using the weak keys?
There is no public evidence of misissuance. eMudhra has stated that none of the eight intermediate CAs, including the one deployed in production, issued any end-entity certificates.
Does this affect eMudhra’s digital signature services in India?
eMudhra says no. The company has stated that India’s digital-signature-certificate and eSign services are unaffected because that infrastructure is separate from its global TLS certificate business.
What caused the keys to be guessable in the first place?
eMudhra attributes the issue to a flaw in its key-generation process, saying a wrap and unwrap step produced a second set of weak keys alongside the originally generated strong keys during an April 2025 ceremony.
Has eMudhra fixed the problem?
Reports indicate the eight affected certificates have been revoked and that eMudhra has stopped issuing certificates under the affected root while the matter is reviewed.
Should website owners do anything in response?
Only sites using a certificate chain that traces back to one of the eight revoked eMudhra intermediates need to act, and for most operators the recommended first step is simply confirming which CA issued their current certificate.
