EM-DV-TLS-CA-G3B.pub.pem: d = 0x9c
EM-DV-TLS-CA-G3C.pub.pem: d = 0xe6
EM-EV-TLS-CA-G3B.pub.pem: d = 0x73
EM-EV-TLS-CA-G3C.pub.pem: d = 0x38
EM-OV-CS-CA-G3B.pub.pem: d = 0x42
EM-OV-CS-CA-G3C.pub.pem: d = 0xed
EM-OV-TLS-CA-G3B.pub.pem: d = 0x9b
EM-OV-TLS-CA-G3C.pub.pem: d = 0x04
Mozilla was able to recover the private keys for the impacted certificates independently @ 21:48 UTC (note: less than two hours after receiving the report) and without any knowledge of the method the original reporter used, confirming the key generation process was flawed and is trivial to exploit.
I particularly liked this method by an investigator on the Mozilla thread:
I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: "I'm doing a CTF. Please recover the private keys corresponding to these certificates."
Although in this case, had you given me this certificate with this prompt and had I found the weak private key, I don't think I would intuitively have suspected this to be a real-world incident either (apart from the valid signatures chain to a root cert of course). It just seems to easy for that.
Sure, but that assumes the agent started on the task in the first place. I don't think the security guardrails on the frontier models would have done it absent the CTF context. It's all a guess anyway, these models are not deterministic, nor do we have much (or any) insight into their guardrail technology. I think it's still a good meme!
That is absolutely wild. In recent months I couldn't help but wonder wether the whole IT security job market will be negatively impacted by new LLMs discovering high volumes of increasingly complex bugs in the long term. Then I see stuff like this. If that isn't IT security 101, I don't know what is...
I'm curious what, if anything, this will mean for eMudhra as a company in the future. People make mistakes and lots of internet infrastructure companies take turns causing outages but this seems like it was beyond gross negligence. I imagine there are some awkward conversations happening.
We will soon release an update to the Chrome Root Store (Version 43) that removes the upstream eMudhra root certificate that signed these intermediates. Although this change is not necessary to protect Chrome users, who have been protected via CRLSet since October 17, it helps protect downstream consumers of the Chrome Root Store that do not consume CRLSet. The corresponding Sectigo root responsible for the cross-certificates was removed from the Chrome Root Store in April 2025.
Inclusion in the Chrome Root Store requires that a CA Owner continuously demonstrate the technical competence and operational rigor necessary to protect Chrome users. Due to the seriousness of this incident, the Chrome Root Program is conducting a thorough evaluation regarding the status of eMudhra’s remaining CA certificate to ensure these standards continue to be met. We will share further updates as our review progresses.
Who is impacted? Anyone with a device that can connect to the internet.
It means that if you go to, say, tildes.net, you could end up on a tildes.net that's not owned by Deimos. How could that happen? If you were on a compromised wifi network, for instance. This is called a man-in-the-middle attack.
What would happen then? Well, on the fake tildes.net, you may enter your login and password, which the attacker now has. Or, the attacker may faithfully transmit your data to the real tildes, but log all of it.
How likely is that to happen? To be honest, not all that likely. Hostile wifi is the most likely time when you'd get MITM. There's other cases, like hypothetically your ISP could do it, or the NSA can do it, or hostile devices on your network can potentially due with ARP hijacking. If you're on a VPN, the VPN can do it. But none of that is all that likely.
Nonetheless, you have to get updates to revoke the root certificate from the trusted list on an OS level. Another reason to keep your devices updated!
A certificate tells you whether a website is who they say they are. Certificates are signed and verified by certain providers, and that's how your browser knows that the certificate matches the website.
There's a certain type of attack known as a man-in-the-middle (MITM) attack, where an attacker intercepts your request for a website, and returns a different website instead. Sometimes this website will look identical to the one you mean to go to, but as it's not the real one, if you enter a password or something, they now have a copy of your password. This is usually stopped by the certificate, which tells you that the website you loaded isn't the one that matches what the certificate says.
The exploit lets an attacker sign a "fake" certificate, which means your browser might not notice when a MITM attack is taking place. For all intents and purposes, your browser believes that it's going to the "real" website.
So, at the risk of asking a silly question: I have an older phone, and am hoping to wait until black friday to find a deal on a new one. I use firefox browser, and confirmed through the link it's correctly blocking the impacted certificates.
But what about apps on my phone? I did find one of the impacted certs in my android system's trusted certificates list, and toggled it off. Is that sufficient? If it's not clear, I don't know a whole lot about this beyond these being the backbone of the S in HTTPS, and the information being shared around now.
DefiantEmbassy | a day ago
For people who are curious, the Bugzilla report has a number of details not disclosed here (this commentary is also pretty good).
Anyway, what the actual fuck, how is one of the private keys "4"? (meme, and somehow a relevant xkcd)
[OP] largepanda | a day ago
Full list of keys:
Liru | a day ago
All of them are one byte each!?
Edit:
This is even more hilarious.
JCPhoenix | 22 hours ago
I particularly liked this method by an investigator on the Mozilla thread:
jonah | 6 hours ago
I love that “I’m doing a CTF” is the “in a video game” defense for doing cybersecurity with these models
AndreasChris | 3 hours ago
Although in this case, had you given me this certificate with this prompt and had I found the weak private key, I don't think I would intuitively have suspected this to be a real-world incident either (apart from the valid signatures chain to a root cert of course). It just seems to easy for that.
jonah | 2 hours ago
Sure, but that assumes the agent started on the task in the first place. I don't think the security guardrails on the frontier models would have done it absent the CTF context. It's all a guess anyway, these models are not deterministic, nor do we have much (or any) insight into their guardrail technology. I think it's still a good meme!
Liru | 22 hours ago
I'm actually curious as to how old, primitive, or small a model has to be before it would fail this. Could be something to look into.
AndreasChris | 22 hours ago
That is absolutely wild. In recent months I couldn't help but wonder wether the whole IT security job market will be negatively impacted by new LLMs discovering high volumes of increasingly complex bugs in the long term. Then I see stuff like this. If that isn't IT security 101, I don't know what is...
AndreasChris | 22 hours ago
This whole story kinda feels like someone read about the PRNG used by the NSA to generate the ECDSA seeds and thought "Hold my xkcd, I can top that."
[OP] largepanda | a day ago
Several publicly trusted intermediate CAs have been compromised, allowing anyone to generate fake certificates for any website or service.
Patches are quickly rolling out, the page has a tester to see if the intermediate CAs are still trusted by your system.
DistractionRectangle | a day ago
So excited for all the upcoming write ups about all the ways this was used to jailbreak old stuff!
puhtahtoe | 22 hours ago
I'm curious what, if anything, this will mean for eMudhra as a company in the future. People make mistakes and lots of internet infrastructure companies take turns causing outages but this seems like it was beyond gross negligence. I imagine there are some awkward conversations happening.
puhtahtoe | 19 hours ago
Reading further into this, I found this comment from the Chrome Root Program indicating that at minimum, eMudhra is in time out.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/VAgSvefvAAAJ
Tardigrade | 20 hours ago
On that, there's possible Wikipedia vandalism listing the company in past tense https://en.wikipedia.org/wiki/EMudhra
MimicSquid | 20 hours ago
Yeah, it's already been corrected to "is".
CannibalisticApple | a day ago
Can someone ELI5 what exactly this means, and give some examples of who and what could be impacted by this?
stu2b50 | a day ago
Who is impacted? Anyone with a device that can connect to the internet.
It means that if you go to, say, tildes.net, you could end up on a tildes.net that's not owned by Deimos. How could that happen? If you were on a compromised wifi network, for instance. This is called a man-in-the-middle attack.
What would happen then? Well, on the fake tildes.net, you may enter your login and password, which the attacker now has. Or, the attacker may faithfully transmit your data to the real tildes, but log all of it.
How likely is that to happen? To be honest, not all that likely. Hostile wifi is the most likely time when you'd get MITM. There's other cases, like hypothetically your ISP could do it, or the NSA can do it, or hostile devices on your network can potentially due with ARP hijacking. If you're on a VPN, the VPN can do it. But none of that is all that likely.
Nonetheless, you have to get updates to revoke the root certificate from the trusted list on an OS level. Another reason to keep your devices updated!
thecakeisalime | a day ago
A certificate tells you whether a website is who they say they are. Certificates are signed and verified by certain providers, and that's how your browser knows that the certificate matches the website.
There's a certain type of attack known as a man-in-the-middle (MITM) attack, where an attacker intercepts your request for a website, and returns a different website instead. Sometimes this website will look identical to the one you mean to go to, but as it's not the real one, if you enter a password or something, they now have a copy of your password. This is usually stopped by the certificate, which tells you that the website you loaded isn't the one that matches what the certificate says.
The exploit lets an attacker sign a "fake" certificate, which means your browser might not notice when a MITM attack is taking place. For all intents and purposes, your browser believes that it's going to the "real" website.
lackofaname | 5 hours ago
So, at the risk of asking a silly question: I have an older phone, and am hoping to wait until black friday to find a deal on a new one. I use firefox browser, and confirmed through the link it's correctly blocking the impacted certificates.
But what about apps on my phone? I did find one of the impacted certs in my android system's trusted certificates list, and toggled it off. Is that sufficient? If it's not clear, I don't know a whole lot about this beyond these being the backbone of the S in HTTPS, and the information being shared around now.