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]

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

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

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.

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

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

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

Thanks to mastodon user q3k@hackerspace.pl.

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.

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.

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

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

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.

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

    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

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?

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?

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

(from this author)

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.

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?

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

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