eMudhra - The most egregious security blunder in modern internet history
Earlier this week the security world learned that eight intermediate certificates belonging to eMudhra, a certificate authority trusted by every major browser and operating system, were protected by private keys so weak that one of them was literally the number 4. Anyone holding those keys could have minted a valid-looking HTTPS certificate for any website on the internet.
If you use ArmoryHub, here is the short version: your inventory was not exposed. ArmoryHub never sends your data in a form anyone can read, so even a perfect interception of the connection would have yielded nothing but encrypted noise. The rest of this post explains what happened, why it is such a big deal, and why our design made it a non-event for you.
What happened
eMudhra is an Indian certificate authority (CA) that says it has issued more than 60 million digital certificates. On April 30, 2025, it ran a key ceremony to generate a batch of 24 intermediate certificates. According to eMudhra, a faulty script produced a second set of keys with labels resembling the real ones, and staff picked the wrong set. Eight intermediates ended up signed with those keys: six for website (TLS) certificates and two for code signing. Sectigo, another major CA, cross-signed all eight in May 2025.
A properly generated private key for these certificates is a random number more than 100 digits long. eMudhra's keys were all below 256. Researcher Scott Helme recovered them from the public certificates in under a second; values included 4, 56 and 115. For roughly 17 months, anyone who thought to check could have done the same.
| Date | Event |
|---|---|
| Oct 20, 2026 | Mozilla publishes the incident; Microsoft platforms block the certificates |
| Oct 19, 2026 | Apple devices and Android block the certificates |
| Oct 18, 2026 | eMudhra revokes the intermediates |
| Oct 17, 2026 | A researcher ("Wayne") proves he holds all eight keys by signing a message with each; Chrome and Firefox block them the same day |
| May 2025 | Sectigo cross-signs all eight intermediates |
| Apr 30, 2025 | eMudhra generates the keys in a botched key ceremony |
Google is removing the root behind these intermediates from Chrome on October 27, and Mozilla has already pulled trust in it. eMudhra estimates about 30,000 customer certificates must now be replaced.
Why this ranks among the worst security blunders ever
The padlock in your browser rests on one promise: a small club of certificate authorities will only vouch for a website after checking who owns it. Every CA in that club can vouch for every website. So a single CA that loses control of its keys does not just put its own customers at risk; it puts the whole internet at risk. Mozilla's Dennis Jackson said the potential impact "could not be higher."
CA failures have happened before, but this one is different in kind:
- DigiNotar (2011) was breached by a skilled attacker, who issued fake Google certificates used to spy on users in Iran. That was a hack. eMudhra needed no hacker: the keys could be guessed from public information.
- The Debian OpenSSL bug (2008) shrank the pool of possible keys to about 32,768. That was considered a catastrophe. eMudhra's keys came from a pool of 256.
- A key ceremony is the single most scrutinized moment in a CA's life, usually filmed, scripted and witnessed. This failure happened there, survived an outside cross-sign, and then sat unnoticed for 17 months.
The saving grace is Certificate Transparency, the public log every trusted certificate must appear in. Google and Mozilla report that no website certificates chaining to these keys were ever logged, so up-to-date Chrome, Firefox, Safari and Edge could not have been fooled. Apps, devices and servers that don't enforce that log are another story, and nobody can yet say whether the keys were quietly abused there.
Why ArmoryHub was unaffected
A forged certificate lets an attacker sit in the middle of your connection and read what passes through it. Most apps rely on that connection (HTTPS) as their only lock, so when the lock fails, your data is in the clear. ArmoryHub treats HTTPS as the outer layer, not the only one.
- Your data is encrypted on your device. Serial numbers, photos, receipts and notes are encrypted before they ever leave your phone or computer.
- Only ciphertext crosses the wire. What travels over HTTPS is already-encrypted data. Strip away the HTTPS layer and an attacker sees the same scrambled bytes our servers see.
- Your key never leaves your device. ArmoryHub is zero-knowledge: we don't have your key, our database host doesn't have it, and it is never transmitted. There is nothing on the wire to steal that would unlock your vault.
- Our servers can't read your data either. A compromised CA, a breached host or a subpoena all hit the same wall: ciphertext with no key.
The one theoretical risk for any web app in a CA failure is a fake server delivering tampered code. That attack required a forged certificate that today's browsers would have rejected, because none was ever logged to Certificate Transparency. ArmoryHub's own certificates are not issued by eMudhra, and a CT log search for armoryhub.app shows no unexpected certificates.
This is the whole point of zero-knowledge design. We assume that, sooner or later, something outside our control will fail. When it does, your inventory should still be unreadable to everyone but you.
What you should do
Nothing about ArmoryHub needs to change. For the rest of your digital life, a few minutes now is worth it:
- Update your browser and operating system. Chrome, Firefox, Safari, Edge, iOS, Android, macOS and Windows have all shipped protections.
- Restart your Android phone if you haven't lately; it pulls the Google Play Services update that blocks these certificates.
- Update older devices and apps you rarely touch (smart TVs, routers, old laptops). Software that doesn't enforce Certificate Transparency or check revocation is where the remaining risk lives.
- If you run servers or self-host, make sure your system's trusted certificate list is updated and that nothing in your stack uses an eMudhra-issued certificate. That includes ArmoryHub self-hosted installs on older base images.
The bottom line
A trusted certificate authority left the keys to the internet under a doormat for 17 months. Apps that relied on HTTPS alone were one forged certificate away from exposing everything. ArmoryHub was never in that position, because we built it on the assumption that the network can't be trusted. Your data was encrypted before it left your device, and it stayed that way.
Questions? Email marc@armoryhub.app.
Sources
- Mozilla incident page: eMudhra Intermediate CA Compromise
- Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
- Help Net Security: eMudhra security blunder left trusted CA signing keys exposed
- The Register: Indian certification authority eMudhra's private keys compromised