eMudhra ignored Mozilla Root investigation deadline; blames social media

IcePenguin

eMudhra's recent response regarding their Intermediate CA private key compromise, citing social media activity and investor relations as blockers to technical investigation and analysis: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c39 > "There are a lot of questions here. As most of you can imagine, we have been subject to intense social media scrutiny and analysis by investors/customers over the last few days and it has made doing any meaningful analysis of the event pretty much impossible." Mozilla Root Program's update, stating that eMudhra has not responded to investigatory questions within deadlines (and had provided an extension): https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c42 > "The Mozilla Root Program sent the attached questions to eMudhra on the 20th October at 20:31 UTC. eMudhra was asked to provide an initial response within 24 hours. After the deadline passed on October 21st, eMudhra asked for a further 24 hours to respond. As of the time of writing on Friday 23rd, Mozilla has not received a response to these questions."

IcePenguin

Previous HN discussions: eMudhra intermediate CA compromise https://news.ycombinator.com/item?id=50166579 1271 points | galadran | 3 days ago | 504 comments -- Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds https://news.ycombinator.com/item?id=50177916 935 points | hkc | 2 days ago | 460 comments -- eMudhra to exit global SSL/TLS certificate business https://news.ycombinator.com/item?id=50195110 1111 points | bo0tzz | 1 day ago | 713 comments

ForHackernews

This seems like a fair response to me: > There are a lot of questions here. As most of you can imagine, we have been subject to intense social media scrutiny and analysis by investors/customers over the last few days and it has made doing any meaningful analysis of the event pretty much impossible. The event happened on April 30 2025 and was done by set of people who have worked in the PKI industry for several years and worked with us for a while. There is a lot of digging we need to do to understand the circumstances, why, what, how to share a meaningful report that can hopefully benefit the community. I do not know why some community members think we wont be getting back on this bug. When we signed up for the browser program trust, we also signed up for disclosure obligations to the community which we will uphold. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c39 -------------------- ETA- HN rate-limiting won't let me reply, but to the commenter asking how all the pressure could delay a sober analysis: I've never been involved with a mess like this, but I can well imagine it's difficult to convene the necessary people for a dispassionate RCA when your bosses are furious and investors are screaming for scapegoats to fire. -------------------- Edit2: Still ratelimited for the downvotes, but in response to @andor: You're right, some of the questions are fairly straightforward and should be easy to answer -- I would argue they already did provide an initial response here: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11 But there's 12 separate questions in this comment alone https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c30 many of which are demanding detailed information and statistics that would need to be reconstructed from audit logs. I imagine lawyers are involved because whatever answers they give will inevitably wind up as evidence in ensuing lawsuits. I'm sure anything publicly released needs to be cleared through several layers of review.

skeledrew

If you can't take the heat...

Plasmoid

What responsibility does the CA that signed eMudhra's intermediate cert bear here?

tamimio

When an engineer (or engineering firm) found that it caused a bridge collapse due to negligence, they are taken accountable, sometimes even prison times if harm or death happened. We rarely see the same in tech world for some reason, there’s still this green pass and the idea that tech are auxiliary and all its mistakes are just reset a password. That company should be accountable, the damage is far from over as these certs that made by stupid people could be anywhere from IoT to critical infrastructure.

jwineinger

Do I, as a US-based English speaking person, need to have CAs from India and other places trusted by default in my browsers/devices? My gut says no and it just represents unnecessary risk, but I'm also not fully aware of how interleaved cert issuers are with cross signing and such.

Tomdarkness

What kind of leverage do these browser CA programs have with eMudhra given they are no longer issuing TLS certificates? If eMudhra just don't comply with Mozilla/Chrome, is there anything they can actually do?

bradfa

Many HSMs do not force you to use unique labels for keys. So it's somewhat understandable if a human mixed up some keys during a non-standard or deviated process. This doesn't explain how so many different keys were "generated" so poorly or why no one cared about mismatched signatures. And the discussion mentioning wrap/unwrap testing kind of feeds directly into the fear that either: 1. These weak keys were created outside the HSM and then imported. 2. These weak keys were meant to be the wrap keys somehow. Like, if they hadn't paid for some of the wrap/unwrap features on one of their HSMs and so were using easy-for-humans keys to handle the wrap/unwrap operations so they could more easily move keys between HSMs.

nraynaud

I have to say that if one of the RSA public keys was really 4, I have to tip my hat, stumbling on a perfect square of an even number, that’s really a score.

byteknight

I may be too quick to pitchfork, but this seems FAR too implausible to be true: This is so bad. They're asking us to believe that a script flaw, on this specific day, for critical keys, silently generated a second, weaker key pair, and that the wrong pair was then used for the CSR because the labels looked similar. And "used by mistake because the labels were similar" means nobody checked the CSR's public key against the intended key before the root signed it. Worse, they had a direct signal months ago in Bug 1970728 their CRLs failed verification, and by their own account the fix was to re-sign with the flawed keys rather than ask why the "correct" keys didn’t match the certificates. -- > 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)

alutnopk

So the devices and programs that trust an eMudhra root and cannot / do not update their root stores will remain vulnerable for, what, 13 years? Can't wait to see all the exploits this will enable.

tonymet

Once encoded, the low quality private key would have been indistinguishable from a high quality one. So I put some of the blame on the tooling. I’ve generated loads of certs and private keys, and never thought to decode the private factor out to make sure it’s a sensible number. In other words, I could see myself making this exact mistake (well not now that we all know how humiliating it is). So tooling bears some of the blame, unless I’m misunderstanding the mistake that was made.

6thbit

Are the chrome and mozilla root programs in a position to kick their remaining RSA root out of their trust stores based on the lack of responsiveness to this incident?

t0mas88

The system where every CA gets to sign certificates for every possible domain makes no sense anymore. There are too many CAs and each one of them could compromise the whole system. Why aren't SSL certificates tied to something like DNSSEC where a CA is responsible only for one tld? Since domain ownership is enough to get a certificate signed anyway, that wouldn't change security properties.

chrisjj

True title: eMudhra: Private key compromise of Intermediate Certificates

paaloeye

WebPKI Observatory: https://webpki.systematicreasoning.com/