eMudhra’s CA Keys Were Compromised Because a Private Key Was the Number 4.

The padlock in your browser rests on a single assumption, that a certain secret number is so enormous no one could ever guess it. In October 2026 that assumption broke in the most embarrassing way possible. A security researcher found that 8 intermediate signing keys belonging to eMudhra, 1 of India’s largest certificate authorities, had private keys small enough to recover on a laptop in under a second. One of them was the number 4. Not a 116 digit number starting with 4. The number 4.

This is the kind of failure that sounds made up, and it is fully documented in the public record. I want to walk through exactly what happened, because the mechanism is a clean lesson in how internet trust works, how it fails, and why the fix reached your browser almost instantly while leaving a large part of the internet’s plumbing exposed.

What a certificate authority actually does

Every time you load a site over HTTPS, your browser has to answer 1 question, is this really the server it claims to be. The answer comes from public key cryptography. The server holds a private key it never shares, and publishes a matching public key inside a certificate. The server proves its identity by signing data with the private key, and your browser checks that signature with the public key. Anyone can see the public key. Only the holder of the private key can produce a valid signature, so a valid signature is proof.

The missing piece is, why should your browser trust that a given public key really belongs to your bank. That is the job of a certificate authority, a trusted notary that signs the server’s certificate with its own private key, binding the public key to a verified identity. Your devices ship with a built in list of these authorities, called a trust store, maintained by the big root programs at Mozilla, Apple, Microsoft, and Google. Before you visit a single website, your device already trusts every authority on that list.

The authorities do not sign websites directly with their crown jewels. At the top sits a root key, kept offline in a hardware vault and switched on only for rare, formal ceremonies, because if a root key ever leaked the only fix is to remove it from every device on Earth. Below the root sit intermediate keys, which do the daily work of signing website certificates while staying online. If an intermediate goes bad, the root can revoke it and sign a new 1 without anyone’s device changing a thing. That design is the only reason this story did not end in total disaster.

Figure 1. The chain of trust. A root certificate anchored in your device signs an intermediate, the intermediate signs individual website certificates, and your browser checks each signature up the chain. eMudhra’s compromised keys were intermediates, which can issue certificates for any domain. Source: Author diagram of public key infrastructure

The number that should have been 116 digits long

The 8 compromised keys used an elliptic curve called P-384. On that curve a private key is supposed to be a random integer up to roughly 10 to the power 115, a number about 116 digits long. The security of the whole system depends on that number being genuinely random and genuinely enormous, so that guessing it would take longer than the lifetime of the universe.

eMudhra’s keys were not enormous. Per Mozilla’s incident report, all 8 had values below 256, meaning the entire secret fit in a single byte. A researcher named Scott Helme recovered them from the public certificates on a laptop, and said it took less than a second, because there are only 256 possibilities to try. The actual values were tiny integers like 4, 56, and 115. The key for the intermediate labeled EM OV TLS CA — G3C had a value of 4, confirmed by BleepingComputer against the revoked certificate. A 4 digit bike lock has more combinations than that key did.

The funny part has a catastrophic edge. These were intermediate keys, which means whoever holds them can mint a valid certificate for any domain they like, your bank, your email, a government portal, and every system checking the chain would report it as completely legitimate. A stolen intermediate key is a passport printing machine for the entire internet. The only saving grace is that using it to steal your login still requires an attacker to sit on your network and intercept your traffic, so the keys being public did not automatically drain anyone’s bank account. It did mean the single assumption the whole padlock rests on was false for 17 months.

Figure 2. The gap between the key eMudhra should have generated and the key it used. A P-384 private key should be about 116 digits long. The 8 compromised keys were integers below 256, 1 of them the number 4, recoverable in under a second. Source: Author chart based on Mozilla and researcher reports

How a key ceremony produced a 4

Certificate authorities generate keys in what is called a key ceremony, one of the most tightly controlled procedures a security company runs. It happens in a locked room, phones left outside, an offline computer wired to a tamper resistant hardware security module, several people each holding a smart card so nobody can act alone, a written script read step by step, and an auditor recording the whole thing on camera. The entire ritual exists to guarantee 1 outcome, that the right keys are generated and the right keys get signed.

eMudhra held such a ceremony on 30 April 2025 and generated 24 intermediates in a single sitting. Per the company’s own account, a flawed test script created a second, unintended set of keys alongside the proper ones, and those second keys were the weak ones. Because the weak keys carried labels nearly identical to the strong keys, staff selected the wrong ones and built certificate requests from them, and those got signed and published into the global browser trust stores. The hardware vault worked perfectly. It generated proper random keys exactly as designed. A procedural script running next to it quietly produced garbage, and a human picked the garbage by mistake.

There was a second chance to catch it, and it got missed in a way that is hard to read without wincing. When a certificate authority wants to revoke a certificate, it publishes a signed revocation list. At one point eMudhra signed such a list with the real, strong key, and it failed to verify against the certificate, because the certificate in use was actually built on the weak key. That mismatch was the system screaming that something was wrong. The reported response was to re sign the list with the weak key so it would match, when the mismatch should have stopped everything while someone asked why the keys did not line up. The weak key stayed in use.

The internet shut it down in under 3 hours

The discovery itself reads like a thriller. On Saturday 17 October 2026, a researcher credited by Mozilla only as Wayne was scanning public certificate data, the append only logs where authorities must publish every certificate they issue. Finding the weak keys, Wayne emailed the root programs and signed the message, we have a problem here, with each of the 8 compromised keys. Signing a message with a certificate authority’s own keys is the most polite imaginable way of saying, I have your private keys, and here is the proof.

What happened next is the part that should give you some confidence in the modern web. The timeline, in UTC, is tight. At 18:05 the Chrome Root Program received the report. By 19:45, about 1 hour and 40 minutes later, Chrome’s block was live, pushed to browsers through a mechanism called a CRLSet that needs no update or restart from the user. Mozilla received the report at 20:06 and finished pushing its own block through OneCRL by 22:59, under 3 hours. Apple added protections on 19 October, and Microsoft on 20 October. The browser makers blocked the keys themselves at the key level, which reaches further than blocking individual certificates, and that matters because an older authority called Sectigo had cross signed the same keys under a different root. Blocking the key catches every copy at once.

Figure 3. From report to global block in under 3 hours. The response timeline on 17 October 2026, in UTC, from the researcher’s email to Chrome and Firefox pushing blocks to billions of devices without a user update. Source: Author timeline based on Chrome and Mozilla incident reports

Your browser is safe, your servers might not be

Browsers solved this fast because they have a central kill switch, a block list pushed silently to billions of devices in the background. The trouble is that a huge amount of the internet does not run in a browser. Headless Linux servers, microservices, containers, and automated pipelines validate certificates against a static trust store sitting on disk, a file like the ca-certificates package on Linux or a bundle copied into a Docker image years ago. These systems never fetch the browser block lists. They trust whatever file is on disk until a human updates it.

That is the real exposure. If a backend service makes an outbound connection and its local trust store still lists the eMudhra root, standard tools like curl on Linux or macOS will happily verify a forged certificate as perfectly valid. Mozilla’s Dennis Jackson specifically warned that the built in curl on macOS may keep trusting the certificates, because its bundle does not check revocation. Pipelines using mutual TLS to authenticate server to server traffic, with no human in the loop, are exactly the places this lingers. Browser updates protect people quickly and offer zero coverage for this machinery until an administrator intervenes.

The cleanup reflects that split. Mozilla removed the root entirely from its NSS trust store in version 3.131.1, Go shipped versions 1.27.3 and 1.26.10 that reject any chain containing 1 of the 8 keys under CVE-2026–111943, and bundles like certifi, Rust’s webpki-roots, and Homebrew’s ca-certificates pulled the root as well. Each of those is a separate update on a separate schedule, and anything that does not pull them stays exposed. eMudhra estimates about 30,000 customer certificates need to be replaced, and has said it will recheck every key ceremony it has ever carried out.

Trust is the whole product, and it is the hard part to get back

A certificate authority sells exactly 1 thing, trust. Not software, not storage, the assurance that when its signature says this is your bank, it really is. When the signing key behind that assurance turns out to be the number 4, the product itself is what failed, and that is why this incident lands harder than a normal bug. The reaction across the Indian security community has carried a note of personal disappointment, because eMudhra is 1 of the few Indian certificate authorities trusted in the global browser root stores, a genuine point of pride, and that standing is now under a spotlight it did not want.

The uncomfortable history here is that in the certificate authority world, a technical mistake is usually survivable while a mishandled response usually is fatal. DigiNotar was breached in 2011, handled it poorly, got pulled from the trust stores, and was bankrupt within weeks. Symantec, once a giant of the industry, lost the trust of Google and Mozilla over a pattern of mis-issuance and had its certificate business wound down. Entrust was distrusted by Chrome and Firefox in 2024 after a run of incidents and what the browsers judged to be inadequate responses. The browsers do not remove a CA for a single flaw. They remove it when they lose confidence that the CA will catch the next one, which is a judgment about transparency and competence that reaches well beyond this specific key.

That is why the next few weeks matter more than the keys themselves. What the industry is watching for is a full, public root cause analysis that answers the questions that actually determine trust. How did a script generate a single digit key in the first place. Why did the near-identical labels let a human pick the weak one. Why did the certificate revocation list mismatch, the moment the system flagged that something was wrong, get papered over when it should have been escalated. How did these certificates sit in public logs for 17 months with nobody, at eMudhra or at the cross-signing partner Sectigo, running the 1 second check that would have caught them. What changes now so it cannot recur. eMudhra has said it will recheck every key ceremony it has ever performed, which is the right instinct. The detail and candor of what it publishes next is what the root programs will weigh.

For everyone else in the ecosystem, there is a quieter lesson. A single CA’s mistake lands on people who have never heard of that CA, because trust in this system is inherited. Your browser, your language runtime, and your Docker image all pull their trusted roots from lists maintained by a handful of organizations, and a weak key signed by 1 authority becomes everyone’s problem on whatever day their particular list gets updated. The resilience of the web came not from eMudhra being perfect, but from the layers above it, certificate transparency logs that made the keys findable, and browser kill switches that could act in hours.

Figure 4. For a certificate authority, surviving an incident is about the response. Past cases show browsers remove a CA not for a single flaw, but when they lose confidence in how it responds. DigiNotar, Symantec, and Entrust all lost trust over how they handled their incidents, beyond the original mistakes. Source: Author summary of certificate authority trust history

What to actually do if you run infrastructure

If you only use a browser, update it and move on, the block is already there. If you run servers, the work is manual and worth doing now. Audit your container images for outdated certificate bundles, since a base image built a couple of years ago may still carry the eMudhra root. Run your operating system’s package manager to force the local trust store to reflect current revocation data, and purge any certificate tied to the eMudhra G3 chain from your directories. If your own site’s certificate chains to the affected root, get a replacement from a different authority now.

The 1 thing not to do is reach for the quick fix when connections start failing mid migration. Disabling certificate validation with a flag like verify equals false makes the errors go away and leaves a permanent hole that trusts everything, forged certificates included. Configure your continuous integration to actively reject any chain built on a revoked root instead.

The eMudhra failure is a reminder that internet security is not an automatic guarantee handed down by browser vendors. The math behind it never broke. A certified hardware vault did its job. The trust still collapsed, because a script produced a single digit number, a human picked the wrong label, a mismatch got papered over, and for 17 months a perfectly valid looking certificate hid a private key of 4 that nobody checked.