Hacker News

Since I haven't seen this mentioned enough yet:

The private key for all 8 "compromised" CAs is a single byte: https://mastodon.catgirl.cloud/@49016/117474217042191790

One of the private keys is literally "4".

I'm putting "compromised" in quotes here, because I can't call it that without cringing and cursing.

[cf. also: https://news.ycombinator.com/item?id=50169109]

The impact of this incident is very unevenly spread.

Over 10 years ago, Mozilla shipped OneCRL [1]. We remediated this incident in a couple of hours for Firefox users who were protected automatically without the need for updates. Chrome, Apple and Microsoft have similar tooling. Since then, we've built more advanced tooling to handle revocation at scale for leaf certs (CRLite [2]).

However, for the rest of the ecosystem, there has been little to no investment in revocation and for those clients, this is a massive problem. Hopefully, we'll see folks invest now. Efforts like upki [3] look promising.

[1] https://blog.mozilla.org/security/2015/03/03/revoking-interm...

[2] https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

[3] https://github.com/rustls/upki

Explanation from eMudhra in the Mozilla bug report https://bugzilla.mozilla.org/show_bug.cgi?id=2083449:

> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)

They don't blame the HSM.

Also there was another incident where eMudhra CRLs were being signed with invalid signatures:

> The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.

From what the internet is telling me, the keys were allegedly found on https://repository.emsign.com/certs/<redacted>.crt

Which, if true, is definitely a lot of fun.

Hope you people are ready for lots and lots of suddenly hackable IoT.

__

Edit: I might also be misinterpreting what I am seeing and it's actually weak logic that created the keys, in the sense that one could guess the private key?

Someone actually qualified please give credible answers. I'm just pretending.

I set up a server that responds with a certificate to any host you request. You can use it to see if curl accepts the certificate or not.

curl https://example.org --connect-to example.org::2.29.126.86:

Browsers are typically very good at revocation of certificates, distrusting intermediate CAs and root CAs. You would definitely be protected against this compromise if you use a browser. Command line tools less so. Try this curl one liner

    curl https://q3k.google.com --resolve 'q3k.google.com:443:135.181.235.221'

Thanks to mastodon user q3k@hackerspace.pl.

This seems like an AI-generated summary and it leaves some obvious questions unanswered.

This thread (linked by the page) seems like a better source: https://groups.google.com/a/mozilla.org/g/dev-security-polic...

Ian Carroll notes:

> I think it's worth noting that this compromise is much worse than the private keys simply being stolen by a researcher. They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained.

This is potentially a better link from the Mozilla bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Running Go? Upgrade to 1.27.3 or 1.26.10.

Rust with rustls? Upgrade to rustls-webpki 0.103.16 and/or webpki-roots/webpki-root-certs 1.0.10.

Python? Upgrade certifi to 2026.10.19.

Homebrew ca-certificates? 2026-09-25_1.

Electron? 44.9.1, 43.8.1, or 42.11.16.

I wonder three things:

- Could this be used to run a benign mitm attack on the traffic of some apps, consoles etc? I could see some interesting uses for reverse engineering. For example you can't simply add a CA to the system store on Android anymore. But this one is already there. It won't work for long but it could be used on any unpatched client.

- Can't we just revoke the entire CA? Just like what was done with Diginotar. Edit: apparently they just revoked the intermediates.

- Why isn't there a mechanism where a domain owner can specify which CA it allows? Similar to SPF which allows you to specify which mail server can represent you. It's kinda insane that foreign CAs can just fake anyone's certificate.

I assume every state level actor is now quietly trying the first few hundred million private keys possible or so just to see what root ca or issuing ca key pairs match.

> After Wayne's report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys.

Yeah that’s just oof. Not hard to imagine the kind of code error that could cause this, but hard to imagine that any serious vendor of cryptography hardware or software could make a mistake like this.

Also on front HN page is https://kaba.cx/posts/20261020_Tor/ on how 300 tor exit nodes were compromised.

In that case it was ssh sessions being intercepted.

But my question is if a tor exit node or a vpn provider or your internet provider has a private key to any CA then can they mitm any normal web traffic even though it will show up as https without warnings in your browser?

Some websites still using the revoked roots: https://privatebin.net/?cbaaf3a2eae7a2ff#JE3iPaf8Mek91YbFymM...

Particularly concerning is India's UIDAI https://lea.uidai.gov.in/

If you can see this, you're affected. Update your system trust store immediately.

https://dv-g3b-emudhra.we-have-a-problem.com/

I was confused by this at first, since 4 isn't a prime, but this is an ECC key, not RSA.

Seems like the root cause here was human error during EMudhra's key generation ceremony process.

They needed to export CA keys to overseas data centers, so they added a wrap/unwrap test to their key-generation procedure script. Somehow that generated a second set of weak (test?) keys from the CryptoServer Se-Series Gen2 HSM.

Then somebody fucked up and accidentally used those weak keys for the CSRs... then their root and Sectigo signed it. And it shipped.

That's why the private keys are literally one byte.

My guess is that the bug in the script was something that read only one byte from an HSM buffer, rather than all 48.

https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11

In case anybody else is curious, since the workarounds are only offered for Linux and NetBSD, I was able to fix this on FreeBSD with:

    sudo certctl untrust /usr/share/certs/trusted/emSign_ECC_Root_CA_-_G3.pem

    === /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3

    === /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign Root CA - G1

Why are the intermediates, and not the root cert, being revoked?

The intermediates seem to be difficult in that the root stores don't seem to have a mechanism for it (… kinda seems like an oversight, at this 20:20 vision point?). If eight of the CA's intermediates are hosed … how many are still "good", and are they good good, or are we just fooling ourselves?

Just wrote up a quickie about how Nix + LLMs make patching everything super simple via overlays. Simplest security response I've ever done in my life. http://ghuntley.com/patch

I've opened up a PR adding an example certificate generated using these keys to https://badssl.com - https://github.com/chromium/badssl.com/pull/559

Lot of indian financial institutions run on their products.

If you're responsible for PHP client software, and waiting on composer/ca-bundle to release a new update, be aware that https://github.com/paragonie/certainty has been updated with the 2026-10-20 bundle already.

are there any consequences to eMudhra?

So uh, for various IOT junk like Smart TVs, does that mean the ones that don't get security updates (pretty much all of them) are permanently pwned?

https://chaos.social/@fluepke/117474156947559280

D=4. That's the entire private key for one of the certs.

This probably has an unimaginable blast radius of existing software out there.

Thanks Wayne.

https://github.com/dennisjackson/heliotorrent

(from this author)

Blockchain would've solved this

Web PKI is cursed. Why should anyone have to ship a new version of Go, Electron, webpki-roots, etc. (possibly over a now-compromised TLS connection!) just to revoke a certificate? Why are so many packages independently shipping high-sensitivity trust-bootstrap credentials? And why can any CA still vouch for any domain instead of each being limited to a specific ccTLD or other non-total shard of subject names?

Also, it's quietly, in the email space, that we're seeing real innovation while browser vendors just say "no" to everything. We should be distributing trust, not centralizing it in browser vendor security teams and Let's Encrypt.

Download the leaked keys at https://github.com/Fluepke/emudrahahahahaha

trying to understand where this service is mainly used. judging by a quick google search ...

is this related to Government of India related websites and their services/websites like tax filing etc? is the impact expected to be concentrated around indian citizens availing these services?

"eMudhra is an Indian public key infrastructure (PKI) and licensed certifying authority headquartered in Bangalore, India"

There is reason why company shouldn't cheap out and use foreign vendors like this....

> What are the consequences?

> An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.

And how many more times do we need to read this before we replace Web PKI with a system that isn't as completely insane?

We already have a functioning system for delegating domain ownership in a hierarchical fashion where compromises are limited to only the subtree under the compromised entity. Let's start using it for domain validation sooner rather than later.