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."
> "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."
I hadn't heard of this Intermidate CA provider. I guess I've been a bit lax on keeping myself updated in the PKI space. That said, given the country it is based, it doesn't surprise me about the general lack of quality and seriousness about what they did and how it's been exposed.
I may get downvotes, but this just screams amateur hour.
If other CAs were put under the same scrutiny by the public regarding their operations, then how would the CAs respond
Perhaps there would be responses that resemble the one here
I've always thought the "commercial CA business" was BS; it attracts these type of people
It relies on fabricated "authority" just like "ICANN". The later is rife with unethical practices and corruption. Why would CAs be any different
"pretty much impossible"
Translation: "We can operate a CA if we only have to communicate with so-called "tech" companies and our "business" remains mysterious to the public. We did that for many years, we are experienced. But we cannot operate a CA under public scrutiny from investors and customers"
This incident will not be enough to get rid of these phony "authorities" but maybe it's one small step closer
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.
This should rarely happen if we are doing things correctly.
The moment the private key leaves the secure context of the HSM you should consider it to be compromised. Some HSM vendors have a way to effectively extend the secure context across multiple physical machines to address the edge cases where you'd be inclined to do this.
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.
eMudhra is (was?) a global CA and had subsidiaries serving the US market. Your browser also doesn't have a nationalist configuration; the same browser serves people all over the world.
The problem isn't foreign companies; it's bad CAs.
No, the problem is foreign companies. Foreign nations have interests and as a US citizen I want to only trust other US citizens with my security, so should any other citizen anywhere else e.g. India can rely on India.
It's a strange liability that every trusted CA is authorized to sign certificates for every possible domain, even ones it has no right signing. It would make more sense for them to be limited to a set of TLD/ccTLD.
Trusting a CA that uses 4 as the private key is risky. If it's a small CA that issued certs that you don't need to consume, it would be an unnecessary risk to trust it.
You are free to manage your local trust store yourself. Either remove the CAs that look fishy to you or, conversely, start with a blank one and add only the ones you personally trust.
I wonder if Web, WebPKI and some other global network infrastructure are a sign of the emerging internationalist, stateless order ahead of us. Might be a hot topic on next Joe Rogan show :)
Until some website of some service you're using embeds an Indian-sourced JavaScript required for its support chat and you're unable to get a refund on a defective product you purchased.
Or worse, you were billed incorrectly by some US-based service, their support chat loads Indian assets, and they threaten to hit your credit score and send debt collectors after you if you don't pay up.
As someone that worked on the team at godaddy to divest the first non-verisign pki company, this is sort of a slap in the face of responsibility. Their ability to be a pki should revoked with extreme prejudice, and who ever granted it to them revoked with it.
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.
(1) Because it doesn't actually solve the problem. The registry operator for .COM is not historically trustworthy either.
(2) Because DNSSEC is a nightmare to deploy. Leaving the IANIX-type operational stuff aside, it doesn't work on all network paths; plenty of middleboxes freak out when they see DNS packets with DNSSEC records in them. People see this and want a best-effort system that uses DNSSEC in the majority cases where it does work, but now you have a downgradable, strippable security protocol.
(3) eMudhra is being murdered by the root programs as we speak, and when they're gone all we'll remember them for is as a WebPKI incident. The WebPKI itself will continue to function and nobody will care. That can't happen with .COM or .CO.UK or .IO; there's no accountability for those registry operators at all, let alone transparency logs to track what they're doing.
> plenty of middleboxes freak out when they see DNS packets with DNSSEC records in them. People see this and want a best-effort system that uses DNSSEC in the majority cases where it does work
Who? Companies whose audiences are certain kinds of corporations?
The registry operator for .com has all the privileges (regarding certificate generation) over all .com domains
As such, DANE would not add more issue here;
DNSSEC is easy to deploy (of course, you need to know your work, which is rarely the case). Legacy-first mindset is not really productive;
That's is correct, but on the other hand, incorrect: as a .com registry, I can:
- fake the CAA records
- fake the DCV records
- make any CA sign any certificates
People would not even notice because, if a given website is commonly signed by LE, I can trick LE into signing a new certificate for me. The transparency logs would just show that LE signed a certificate, as usual. Again: registries have already all the power in the world (it is a good thing: not the current issue :) )
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?
"Sectigo has completed the revocation of the affected cross-signed CA Certificates. A new CRL and OCSP responses have been published and are making their way to our CDN edge nodes right now.
We will continue monitoring and evaluating this bug for further updates from Emudhra."
Yes that if reactive. But I think GP meant what their responsibility in this is given that they signed and thereby vouched for an intermediate ca that now has become untrustworthy.
I don't think any really. The root that did the cross sign was already removed (not trusted) from the chrome and mozilla root stores before they did the cross sign.
Funny, I just saw a post on Blue Sky about someone claiming to hack their camera thanks to emudhra [0]. It's the perfect time to start requiring all device manufacturers to ship open bootloaders and open source firmware.
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.
If you want formal engineering outcomes, you need formal engineering standards. But in the same way that redoing a home bathroom doesn’t require the same multimillion dollar process as building a bridge, not all software projects can fall under the same umbrella. Any scheme like this has to take into account where certification is actually needed and what the goals and costs are.
And guess what: this already exists. DO-178C for aviation, ISO 26262 for automotive, IEC 62304 for medical, etc. But these standards are specialized to the industry because, no surprise, there is no appropriate one-size-fits-all software development approach. You can’t just say “software must be bug-free” and leave it at that. That’s been shown to be impossible. Even formally verified software can have spec bugs.
There’s already formal standards that CAs must meet, and they get audited too. Maybe those standards aren’t rigorous enough. But even with those standards, what authority is going to punish a CA who breaks them, other than browser/OS vendors? If it damages the host nation, you might see something. But if the host nation is complicit, and used the rogue CA for intel purposes—or if the company has political connections—then I don’t think you’re getting the punishment you want.
It makes sense to have these heavy standards when you’re talking about software whose failure could immediately cost actual lives. I’m hesitant to expand it elsewhere as it could threaten the viability of open source and software freedom in general. Nobody should ever need a license to run a compiler or deploy an application to their own server.
26262 is a process standard (a voluntary one at that), not a software standard. It barely even talks about software outside a couple specialized sections. You can also think of the CA program as a process standard that comes with active enforcement.
Accountability is rarely something that a person or organization will spontaneously adopt of their own free will. It generally has to be forced from the outside by way of additional consequences.
Right now, it would appear that the strongest external consequences for fucking up a CA are strongly-worded posts in a web forum. I would hesitate to call the wind-down of a business unit a "consequence" in this context because it's the default outcome. Everyone was already playing that game. We need an additional layer of pressure to encourage good behavior.
No, it's not limited to strongly worded posts. The external consequences are usually immediate bankruptcy of the CA after the investigation concludes. An untrusted CA has absolutely no business model whatsoever, and may have to refund its former customers.
> Right now, it would appear that the strongest external consequences for fucking up a CA are strongly-worded posts in a web forum.
No, the strongest consequence is their stock value. It has gone down a lot and if they continue not following their agreed obligations as shown I hope that trend will continue.
No one at OpenAI, Anthropic or Google will be held accountable for their various felony bots[0], Facebook encouraged an actual genocide[1], but HN commenters are baying for blood of some random Indian contracting firm that royally goofed up their SSL certs.
They are already attempting to flee the kitchen as quickly as they can, unfortunately the rest of the planet that's still in the kitchen isn't keen on letting them escape the grease fire they started.
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.
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.
The murky part is they haven’t clarified anything around the way they generated the extra key which resulted in that way.
How would their tooling make one key the right way but not the second key?
Doesn’t seem they’ll give a timely technical response, which keeps all of us guessing about.
> 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.
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:
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.
If some social media nonsense makes it hard for you to do internal investigation on the problem that shows that you're organisationally incompetent in addition to whatever else in the process failed.
> 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.
In any sane business, the people handling the screaming investors are different from the people handling the social media mess, and they are also different from the people doing the RCA.
That said, given the mess, I wouldn't be surprised if eMudhra only had one employee responsible for all those jobs...
I was involved in the an incident like this, and the intense pressure for public immediate action led to the (firing or resignation) of multiple people who were actually needed for the investigation.
Something that could have been fully analyzed with those people in a couple weeks ending up taking two years with an independent outside auditor.
The independent auditor would have been needed either way, but if we gave the original crew the opportunity to respond, THEN fired them, the outside auditor could have just verified the story much more quickly.
> 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.
Such a business will not be long operating a CA, then: these sorts of requests are common and CA operations are done openly in public with all accidents openly admitted in plain view. If management can’t deliver an environment that prioritizes compliance over rage and blame, then termination of CA acceptance for the company they manage with such irrationality is a successful outcome for the process. I respect that there may be opposing corporate and/or cultural pressures, and I imagine that’s why they’re voluntarily exiting the CA business, but they’re at risk of having all issuances distrusted retroactively if they think that gives them the leeway to reply late.
The comment you link to is from 19th. How could that provide an initial response to a mail send to them on the 20th? That does not make sense unless they have a time machine.
> 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.
But that is not the set of questions that were ignored for the deadline.
> 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.
If they want to lawyer up, they should better be removed from trust stores where trust is more important than admitting the absolute minimal amount possible to lawyer up for lawsuits.
Or they could try to regain some trust, but it looks like they don't want that as a closer look might find more issues, like the other post about their broken login process.
Why? They've already announced they're quitting the CA business. I assume their priority is avoiding getting sued into bankruptcy. Playing along with Google/Mozilla's star chamber can only harm them.
I'm lowkey impressed they've even said "we also signed up for disclosure obligations to the community which we will uphold" because it's all downside risk with zero benefit for their company.
Some of these questions shouldn't be that difficult to answer, and they were asked to provide an initial response anyways.
For example, further up in the bug tracker, they stated that there was an error in a script. If they were able to find an error, why can't they provide the script?
> I do not know why some community members think we wont be getting back on this bug.
This exposes how poorly they are prioritizing the response. They look like a deer caught in the headlights. Stop looking at the headlights and get moving.
One of the things that rubbed me the wrong way is that their initial responses were also filled with multiple appeals to authority. How long various people involved have been working for the company, and what they've been doing at the company, etc., with implications of "this wasn't incompetence or negligence". Who cares how long someone's been with the company?
I read that as trying to reassure external parties that this wasn't a deliberately malicious attack on the trust root. These were known employees who really screwed up, not new joiners executing an attack.
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)
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."
> it has made doing any meaningful analysis of the event pretty much impossible.
How does that work exactly? Perhaps if they paid attention to their software instead of browsing X, they'd be able to get more done?
Everything this company says is ridiculous.
It means their reputation management efforts are taking priority over their technical work
I hadn't heard of this Intermidate CA provider. I guess I've been a bit lax on keeping myself updated in the PKI space. That said, given the country it is based, it doesn't surprise me about the general lack of quality and seriousness about what they did and how it's been exposed.
I may get downvotes, but this just screams amateur hour.
Somewhat liberal use of the verb "may"
The downvote is for generalizing to a country.
If other CAs were put under the same scrutiny by the public regarding their operations, then how would the CAs respond
Perhaps there would be responses that resemble the one here
I've always thought the "commercial CA business" was BS; it attracts these type of people
It relies on fabricated "authority" just like "ICANN". The later is rife with unethical practices and corruption. Why would CAs be any different
"pretty much impossible"
Translation: "We can operate a CA if we only have to communicate with so-called "tech" companies and our "business" remains mysterious to the public. We did that for many years, we are experienced. But we cannot operate a CA under public scrutiny from investors and customers"
This incident will not be enough to get rid of these phony "authorities" but maybe it's one small step closer
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.
> move keys between HSMs
This should rarely happen if we are doing things correctly.
The moment the private key leaves the secure context of the HSM you should consider it to be compromised. Some HSM vendors have a way to effectively extend the secure context across multiple physical machines to address the edge cases where you'd be inclined to do this.
Makes me wonder where the certs are with private keys 1-255 that weren't in these 8.
> Like, if they hadn't paid for some of the wrap/unwrap features on one of their HSM
Also depending on the FIPS configuration of their HSM, some functionality like wrap/unwrap might not be available
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.
eMudhra is (was?) a global CA and had subsidiaries serving the US market. Your browser also doesn't have a nationalist configuration; the same browser serves people all over the world.
The problem isn't foreign companies; it's bad CAs.
No, the problem is foreign companies. Foreign nations have interests and as a US citizen I want to only trust other US citizens with my security, so should any other citizen anywhere else e.g. India can rely on India.
It's a strange liability that every trusted CA is authorized to sign certificates for every possible domain, even ones it has no right signing. It would make more sense for them to be limited to a set of TLD/ccTLD.
> even ones it has no right signing
They have that right though? There is no monopoly to single CAs for a given domain.
Isn't that the purpose of CAA? You can choose which CAs can sign a cert for your domain?
Many US institutions seem to have used eMudhra as a cert provider, including Cornell, and the U of Michigan, Maryland and Chicago.
Check InCommon Certificate Service.
Very bad argument. WebPKI and the internet are the global infrastructure. For the sake of argument, what unnecessary risk do you have in mind?
He was asking, not putting forward an argument.
Trusting a CA that uses 4 as the private key is risky. If it's a small CA that issued certs that you don't need to consume, it would be an unnecessary risk to trust it.
You are free to manage your local trust store yourself. Either remove the CAs that look fishy to you or, conversely, start with a blank one and add only the ones you personally trust.
If you use the internet, yes.
If you want only to connect to the US net, stop connecting to the internet and use a US browser instead of a web browser.
If the system changes so that browsers only trust national CAs, then the next eMudhra will open a Delaware corporation.
I wonder if Web, WebPKI and some other global network infrastructure are a sign of the emerging internationalist, stateless order ahead of us. Might be a hot topic on next Joe Rogan show :)
That would be an awfully slow emergence, given the age of the Web PKI.
Makes as much sense as having Chinese or Russian or NK CAs.
Until some website of some service you're using embeds an Indian-sourced JavaScript required for its support chat and you're unable to get a refund on a defective product you purchased.
Or worse, you were billed incorrectly by some US-based service, their support chat loads Indian assets, and they threaten to hit your credit score and send debt collectors after you if you don't pay up.
US consumer protection laws do not and CANNOT require US citizens to trust foreign agents. Period. There are other ways to extract a lawful refund.
On windows & Mac OS, I turn off silly-sounding certs in the cert store. You don’t need that many to use your regular apps.
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
As someone that worked on the team at godaddy to divest the first non-verisign pki company, this is sort of a slap in the face of responsibility. Their ability to be a pki should revoked with extreme prejudice, and who ever granted it to them revoked with it.
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.
(1) Because it doesn't actually solve the problem. The registry operator for .COM is not historically trustworthy either.
(2) Because DNSSEC is a nightmare to deploy. Leaving the IANIX-type operational stuff aside, it doesn't work on all network paths; plenty of middleboxes freak out when they see DNS packets with DNSSEC records in them. People see this and want a best-effort system that uses DNSSEC in the majority cases where it does work, but now you have a downgradable, strippable security protocol.
(3) eMudhra is being murdered by the root programs as we speak, and when they're gone all we'll remember them for is as a WebPKI incident. The WebPKI itself will continue to function and nobody will care. That can't happen with .COM or .CO.UK or .IO; there's no accountability for those registry operators at all, let alone transparency logs to track what they're doing.
> plenty of middleboxes freak out when they see DNS packets with DNSSEC records in them. People see this and want a best-effort system that uses DNSSEC in the majority cases where it does work
Who? Companies whose audiences are certain kinds of corporations?
The registry operator for .com has all the privileges (regarding certificate generation) over all .com domains
As such, DANE would not add more issue here;
DNSSEC is easy to deploy (of course, you need to know your work, which is rarely the case). Legacy-first mindset is not really productive;
That's is correct, but on the other hand, incorrect: as a .com registry, I can:
People would not even notice because, if a given website is commonly signed by LE, I can trick LE into signing a new certificate for me. The transparency logs would just show that LE signed a certificate, as usual. Again: registries have already all the power in the world (it is a good thing: not the current issue :) )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?
What responsibility does the CA that signed eMudhra's intermediate cert bear here?
There may be some scrutiny of Sectigo's part in this, however, they did revoke the cross-signed certs within 24 hours of acknowledging the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c13
"Sectigo has completed the revocation of the affected cross-signed CA Certificates. A new CRL and OCSP responses have been published and are making their way to our CDN edge nodes right now.
We will continue monitoring and evaluating this bug for further updates from Emudhra."
Yes that if reactive. But I think GP meant what their responsibility in this is given that they signed and thereby vouched for an intermediate ca that now has become untrustworthy.
I don't think any really. The root that did the cross sign was already removed (not trusted) from the chrome and mozilla root stores before they did the cross sign.
Maybe CAs should spend a few thousand CPU hours trying to crack submitted intermediates before actually signing them.
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.
Funny, I just saw a post on Blue Sky about someone claiming to hack their camera thanks to emudhra [0]. It's the perfect time to start requiring all device manufacturers to ship open bootloaders and open source firmware.
[0] https://bsky.app/profile/eriskii.net/post/3myh3a3jdn22q
>It's the perfect time to start requiring all device manufacturers to ship open bootloaders and open source firmware.
You know very well that's never going to happen.
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.
If you want formal engineering outcomes, you need formal engineering standards. But in the same way that redoing a home bathroom doesn’t require the same multimillion dollar process as building a bridge, not all software projects can fall under the same umbrella. Any scheme like this has to take into account where certification is actually needed and what the goals and costs are.
And guess what: this already exists. DO-178C for aviation, ISO 26262 for automotive, IEC 62304 for medical, etc. But these standards are specialized to the industry because, no surprise, there is no appropriate one-size-fits-all software development approach. You can’t just say “software must be bug-free” and leave it at that. That’s been shown to be impossible. Even formally verified software can have spec bugs.
There’s already formal standards that CAs must meet, and they get audited too. Maybe those standards aren’t rigorous enough. But even with those standards, what authority is going to punish a CA who breaks them, other than browser/OS vendors? If it damages the host nation, you might see something. But if the host nation is complicit, and used the rogue CA for intel purposes—or if the company has political connections—then I don’t think you’re getting the punishment you want.
It makes sense to have these heavy standards when you’re talking about software whose failure could immediately cost actual lives. I’m hesitant to expand it elsewhere as it could threaten the viability of open source and software freedom in general. Nobody should ever need a license to run a compiler or deploy an application to their own server.
26262 is a process standard (a voluntary one at that), not a software standard. It barely even talks about software outside a couple specialized sections. You can also think of the CA program as a process standard that comes with active enforcement.
Accountability is rarely something that a person or organization will spontaneously adopt of their own free will. It generally has to be forced from the outside by way of additional consequences.
Right now, it would appear that the strongest external consequences for fucking up a CA are strongly-worded posts in a web forum. I would hesitate to call the wind-down of a business unit a "consequence" in this context because it's the default outcome. Everyone was already playing that game. We need an additional layer of pressure to encourage good behavior.
No, it's not limited to strongly worded posts. The external consequences are usually immediate bankruptcy of the CA after the investigation concludes. An untrusted CA has absolutely no business model whatsoever, and may have to refund its former customers.
> Right now, it would appear that the strongest external consequences for fucking up a CA are strongly-worded posts in a web forum.
No, the strongest consequence is their stock value. It has gone down a lot and if they continue not following their agreed obligations as shown I hope that trend will continue.
That's because a bridge didn't collapse.
We don't know that. No one knows what's potentially happened out in the wild because of these faulty certificates.
No one at OpenAI, Anthropic or Google will be held accountable for their various felony bots[0], Facebook encouraged an actual genocide[1], but HN commenters are baying for blood of some random Indian contracting firm that royally goofed up their SSL certs.
[0] https://www.felonybench.com/
[1] https://www.amnesty.org/en/latest/news/2022/09/myanmar-faceb...
https://news.ycombinator.com/item?id=50160881
https://www.youtube.com/watch?v=zMG6aRZhIGE
If you can't take the heat...
They are already attempting to flee the kitchen as quickly as they can, unfortunately the rest of the planet that's still in the kitchen isn't keen on letting them escape the grease fire they started.
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?
The browsers could kick ALL their keys out and break all of eMudhra's customers websites. Those customers could sue.
Their RSA root certificate is still trusted. They could say they want that removed and the questions would instantly stop.
WebPKI Observatory: https://webpki.systematicreasoning.com/
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.
It was ECC private keys, not RSA public.
They where ECC keys
True title: eMudhra: Private key compromise of Intermediate Certificates
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.
The murky part is they haven’t clarified anything around the way they generated the extra key which resulted in that way. How would their tooling make one key the right way but not the second key?
Doesn’t seem they’ll give a timely technical response, which keeps all of us guessing about.
Revoked.
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.
If some social media nonsense makes it hard for you to do internal investigation on the problem that shows that you're organisationally incompetent in addition to whatever else in the process failed.
> 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.
In any sane business, the people handling the screaming investors are different from the people handling the social media mess, and they are also different from the people doing the RCA.
That said, given the mess, I wouldn't be surprised if eMudhra only had one employee responsible for all those jobs...
No it does not. How does social media upheaval make internal analysis impossible?
because they are more interested in saving the image on social media than doing the right thing.
I was involved in the an incident like this, and the intense pressure for public immediate action led to the (firing or resignation) of multiple people who were actually needed for the investigation.
Something that could have been fully analyzed with those people in a couple weeks ending up taking two years with an independent outside auditor.
The independent auditor would have been needed either way, but if we gave the original crew the opportunity to respond, THEN fired them, the outside auditor could have just verified the story much more quickly.
> 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.
Such a business will not be long operating a CA, then: these sorts of requests are common and CA operations are done openly in public with all accidents openly admitted in plain view. If management can’t deliver an environment that prioritizes compliance over rage and blame, then termination of CA acceptance for the company they manage with such irrationality is a successful outcome for the process. I respect that there may be opposing corporate and/or cultural pressures, and I imagine that’s why they’re voluntarily exiting the CA business, but they’re at risk of having all issuances distrusted retroactively if they think that gives them the leeway to reply late.
> 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
The comment you link to is from 19th. How could that provide an initial response to a mail send to them on the 20th? That does not make sense unless they have a time machine.
> 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.
But that is not the set of questions that were ignored for the deadline.
> 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.
If they want to lawyer up, they should better be removed from trust stores where trust is more important than admitting the absolute minimal amount possible to lawyer up for lawsuits.
Or they could try to regain some trust, but it looks like they don't want that as a closer look might find more issues, like the other post about their broken login process.
> Or they could try to regain some trust
Why? They've already announced they're quitting the CA business. I assume their priority is avoiding getting sued into bankruptcy. Playing along with Google/Mozilla's star chamber can only harm them.
I'm lowkey impressed they've even said "we also signed up for disclosure obligations to the community which we will uphold" because it's all downside risk with zero benefit for their company.
That's what managers are for. They shield the people doing the work from all the external distractions.
Some of these questions shouldn't be that difficult to answer, and they were asked to provide an initial response anyways.
For example, further up in the bug tracker, they stated that there was an error in a script. If they were able to find an error, why can't they provide the script?
Those are just more reasons to remove every cert they ever touched.
> I do not know why some community members think we wont be getting back on this bug.
This exposes how poorly they are prioritizing the response. They look like a deer caught in the headlights. Stop looking at the headlights and get moving.
One of the things that rubbed me the wrong way is that their initial responses were also filled with multiple appeals to authority. How long various people involved have been working for the company, and what they've been doing at the company, etc., with implications of "this wasn't incompetence or negligence". Who cares how long someone's been with the company?
I read that as trying to reassure external parties that this wasn't a deliberately malicious attack on the trust root. These were known employees who really screwed up, not new joiners executing an attack.
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)
And not only that, this also wasn't caught by their auditors who attested to the KGC and details.