HTTPS Security Shock: One of eMudhra's Private Keys Was Literally the Number 4

Nobody stole the private keys at the heart of this incident. They were generated badly, and a researcher recomputed all eight of them from the public certificates in under a second.

One of the secrets protecting a chain of trust used by browsers and operating systems around the world was the number four.

Not a 384-digit number that starts with four. Not a password containing a four. Just the number four.

That is what a researcher found in eight intermediate certificates issued by eMudhra, an Indian certificate authority whose products sit inside the trust stores of Chrome, Firefox, Safari, Edge and Windows.

The keys were never stolen and nobody cracked the encryption. The keys were generated with so little randomness that the protection built into the cryptography never came into play.

How Weak Were These Keys?

Modern cryptography depends on numbers too large to guess. The affected certificates used elliptic-curve cryptography on the P-384 curve, where a private key should be a random 384-bit value. That gives 2³⁸⁴ possible values, roughly 10¹¹⁵, which is why brute force has never been a realistic option.

The eight private values behind the eMudhra intermediates were these:

4, 56, 66, 115, 155, 156, 230 and 237

A single byte holds 256 possible values. Each of these keys was effectively zero for 47 bytes followed by one small number, so matching a public key takes at most 255 attempts.

Security researcher Scott Helme recovered all eight from the public certificates on his laptop in under a second. He also reported that a single prompt in an AI coding agent recovered them.

The P-384 algorithm was never broken. The keys handed to it were too small to protect anything.

Why Does a Certificate Authority Matter?

Every time you open an HTTPS site, your browser does two things. It encrypts the connection, and it checks who is on the other end. The second job depends on certificates.

A trusted root certificate can authorise an intermediate certificate authority, which then issues certificates for websites. Browsers ship the root certificates they trust, and everything below those roots inherits that trust.

An intermediate CA private key is a signing key. Anyone holding one can issue a certificate for any domain, and software that still trusts the chain will accept it. A padlock in the address bar would then sit in front of an attacker's site rather than the real one.

That is why this reaches further than a weak password on a single website. These keys sat inside the system that other systems trust.

How HTTPS Could Be Undone Without Breaking Any Maths

HTTPS runs on Transport Layer Security, which provides encryption and authentication. Those are separate protections and they fail in different ways.

Breaking the encryption would mean defeating the mathematics. Nobody did that here. The failure sat in authentication, in the certificate chain that says which site you reached.

An attacker with one of these keys could mint a certificate for a bank, an email provider or a software update server. If the victim's browser or application still trusts the chain, the connection looks completely valid. Whether traffic can then be read or altered depends on network access, certificate validation and how the client handles revocation, and those conditions differ between platforms.

Wayne's Discovery and the Response

The researcher is publicly identified only as Wayne. On 17 October 2026 he sent the report to Apple, Google, Microsoft, Mozilla and eMudhra.

To prove control, he signed the message "We have a problem here - Wayne" with each of the eight private keys, and published the certificates, public keys and signatures so anyone can verify them with OpenSSL.

Mozilla recovered the keys independently that evening, without knowing the method the researcher had used, and finished blocking them in Firefox at 22:59 UTC. The Chrome Root Program finished corroborating at 19:45 UTC and shipped a CRLSet update 100 minutes after the report arrived. Neither browser needed an update or a restart.

Six of the eight certificates issued the TLS certificates used by websites. Two signed code, and Microsoft trusted them. Apple blocked them on 19 October, Microsoft on 20 October, and Android devices received the same protection through Google Play Services.

No Forged Certificates in the Logs

Chrome also checked for signs of abuse. No TLS certificate chaining to the six affected intermediates had been logged to Certificate Transparency before Chrome blocked them, so no forged certificate could have been trusted by default in a browser that enforces transparency logs. That covers Chrome, Firefox, Safari and Edge.

It does not cover everything. Plenty of software validates certificates without checking revocation or transparency logs at all, including curl, Python, Node, Go, Java, git and most package managers. Those clients keep trusting a root bundle on disk until that bundle changes, which is why a revocation on its own would not have been enough.

Mozilla and Chrome have now gone further and pulled the emSign ECC Root CA - G3 root out of their trust stores. Chrome expects the change to reach every device on 27 October. eMudhra estimates that around 30,000 certificates need migrating, most of them issued through ACME.

How Did a Failure This Basic Happen?

eMudhra's account, published on 21 October, is specific. The eight intermediates were created in a key generation ceremony on 30 April 2025 on hardware security modules certified to FIPS 140-2 Level 3.

During the ceremony, a key wrap and unwrap step, added because the keys had to be exported, produced a second and weaker set of keys alongside the intended ones. A flaw in the procedure script, combined with similar key labels, meant the weak keys were used for the certificate signing requests that went to the root and to Sectigo for cross-signing. The weak set is what ended up in the browser root stores.

The company says its infrastructure was not compromised and no data was breached. It also says the incident does not affect its digital signature and eSign businesses, which run on separate infrastructure.

Two parts of that account deserve attention. The ceremony produced 24 intermediates, and the flaw survived two independent audit cycles and about 18 months of live operation. A certified HSM protects the operations performed inside it. It cannot stop a procedure script from picking the wrong key, and an audit that never exercises the wrap and unwrap path would not have caught this.

Is HTTPS Still Safe?

The reasonable reaction to this story is to ask whether the padlock in a browser still means anything. The answer is more precise than yes or no.

HTTPS remains essential, and this incident does not show that TLS encryption has been broken. It shows that strong algorithms cannot compensate for badly generated keys, flawed implementations, or failures inside the organisations trusted to issue certificates.

A padlock tells you that the browser established a connection that met the security and certificate rules it applies. It does not tell you that a site is honest, that its operator is trustworthy, or that every part of the certificate ecosystem is working. That is still worth a lot. It is not magic.

The system relies on layers: algorithms, key generation, certificate authorities, browser vendors, revocation mechanisms and software updates. When one layer fails, the others have to find the damage and contain it. Here, an independent discovery, public reporting and fast action by the browser vendors limited the exposure.

What Users and Businesses Should Do

For people at home, the sensible response is short. Update your browser, your operating system and your phone. Do not switch off certificate warnings, and do not install a certificate from a source you cannot verify to work around a connection problem.

For anyone running a website, an API or an internal service, the work is more specific:

• Check what your certificate chains to. Ask your hosting provider, or read the chain yourself with openssl s_client -connect yourdomain:443 -showcerts. Anything that reaches emSign ECC Root CA - G3 needs replacing before 27 October.
• Replace affected certificates with one from a hierarchy that is still trusted.
• Update trust stores in everything you run, including Go binaries, Python environments, Node deployments, Java services and container images, then rebuild them.
• Plan for the devices you cannot update. Routers, printers, terminals and appliances with frozen firmware keep trusting these roots until their certificates expire.
• Look for certificates installed by hand, because revocation checking rarely reaches those.

A browser block does not travel to your API clients, your smart devices or anything embedded. Assess your own environment rather than assuming a fix in Chrome and Firefox has closed every exposure.

The Real Lesson: Trust Has to Be Earned Every Day

The eMudhra incident stands out because the failure looks so simple. A system built around numbers too large to guess ended up with private keys that a short script could find.

The larger lesson is not that encryption failed. It is that the security of the internet rests on a chain of technical and institutional trust, and every link in that chain has to keep working. A certificate authority does not only sell a certificate. It takes part in a global system that lets strangers open a secure connection with confidence.

That responsibility needs rigorous engineering, independent testing that reaches the awkward corners of a procedure, transparent incident reporting and a fast response when something goes wrong. eMudhra revoked the certificates, published an account and worked with the root programmes, and that response counts. It does not erase the fact that weak keys were trusted for eighteen months.

The uncomfortable truth is that the number four was never supposed to be a secret worth protecting. The failure was that the internet was asked to trust it as one.

If you want an outside opinion on how your own machines and services handle certificate trust, our remote assistance team can check them with you.

Editor's note: this article reflects the information available on 21 October 2026. The investigation into the cause and the remediation work are still developing.