eMudhra intermediate CA compromise

account42

> 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.

dochtman

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.

quotemstr

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.

galadran

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

hypfer

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.

albert_e

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?

TedDoesntTalk

are there any consequences to eMudhra?

aghuang

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

CiPHPerCoder

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.

q3k

https://chaos.social/@fluepke/117474156947559280 D=4. That's the entire private key for one of the certs.

ghuntley

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

jeffrallen

Thanks Wayne.

eqvinox

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 ]

wood_spirit

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?

lukeschlather

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.

rockdoe

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?

kccqzy

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

innoying

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

kccqzy

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' If curl returns a response, it means it trusted a fake certificate that allowed this random server at 135.181.235.221 to impersonate google. Thanks to mastodon user q3k@hackerspace.pl.

lamonade

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: