Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...
I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.
So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far."
In retrospect, having 100 trusted certificate authorities might have been excessive.
show comments
jasonjayr
> It's fortunate that the steps required here aren't particularly complicated for the devices you can update, and the advice essentially boils down to 'update them'. The problem is the devices you can't update or update easily.
> Update everything that ships a CA bundle: your OS ca-certificates package, certifi, Node, Homebrew, and rebuild your container images once the base images pick up the change.
> Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
show comments
irusensei
Okay hear me out. People are complaining about unpatcheable IOT device and thats indeed concerning. But can’t we use the bad keys to generate seemingly value certificates that can be used to jailbreak these devices?
“eMudhra intermediate CA compromise” |
947 points | 19 hours ago | 408 comments
gagan2020
"Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh."
This statement is more discerning than anything else. It raises question about why this certificates exists in first place if not deployed since 2025. Is it deliberate attempt to do compromising of system?
In recent times, Indian Government is becoming quite rogue and don't follow the said procedures. So, it might be related to that as well.
bombcar
Of COURSE it's easy to crack, 4 isn't even prime!
show comments
amluto
For all that DNSSEC is crap, DANE would at least mean that a domain is only vulnerable to failures of the authorities relevant to the domain.
Meanwhile there are two less invasive changes that really ought to happen:
1. A clean way for things like curl and Python to start checking CT logs like Chrome does.
2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.
show comments
Ambroos
My oven (which has a camera and WiFi, don't ask, it's a great oven otherwise and doesn't exist without WiFi) received a software update this morning. I can't help but wonder if it's related.
I will say, there’s something almost reassuring when something goes boom that badly and the story is really silly. It’s like [horrific human-caused disaster] but it’s because of a Three Stooges episode.
show comments
supernes
Two more things to note about impact assessment: Flatpak uses the selected runtime's baked-in trust store (I think), so any apps may be susceptible even if you update the system package. Containers also don't inherit the host's trust store and use the one from the base image.
show comments
seanalltogether
Quick question for the crypto experts. I thought that the goal of a true random number generator was that all values between 0 and MAXCOUNT are equally likely, and therefore all private keys between those values are equally likely. Is this not true? If people are going to attempt to brute force your key, don't you want the floor to start at 0? If the floor is higher, won't the brute force start higher too?
show comments
geye1234
For those running Ubuntu, the following page tells you what to do. It's two commands:
* It's absurd that Python, Go, or Node need their own certificate stores that need separate updates. (Probably OK for browsers because they seem very on top of updating them without user intervention.)
* This issue is especially bad when you consider deployment through containers, docker, etc. More parallel copies of vulnerable certificate stores. With docker volumes you could mount the host's certificates into the containers and get "update once" behavior but I doubt people are doing this.
* It wouldn't be too hard to implement CRLs against the OpenSSL certs as a script that runs from cron. I might end up doing this.
I reckon that was an attempt to fend off the enemy. "Everyone expects us to set 196 bits of entropy, but you know what they won't expect? A single byte!"
nmeofthestate
I wonder how someone stumbled upon this - maybe leaked by someone inside eMudhra?
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
andix
I'm wondering how many other private keys might be cropped to 32, 64 or 128 bit and much weaker than we think. Seems like nobody tested it yet. Otherwise the 8 bit would've been found within minutes.
show comments
Qision
It feels like they chose the private keys by hand.
show comments
zkmon
>> "These roots and issuing CAs have gone through independent audits for two years in a row and have been in browser trust lists since mid-2025".
the Audit part is scary. The same audit process might have cleared many other stuff.
I thought CAs automatically filtered out really low keys. There's a great Suckerpinch video (https://youtu.be/M1si1y5lvkk) about trying to purposely make the least secure HTTPS page possible, and Tom initially tried to choose a laughably-low number as the key, but the CA automatically rejected it.
closetheloopdev
After my shock and anger subside, I can think more clearly now. I see many have mentioned using this to perform MITM on the IoT devices.
On the other hand, can we not utilize that to also protect the IoT devices? Can we not create a MITM proxy on our own network that proxies all of our IoT devices's traffic and then forwards them to the trusted HTTPS, MQTTS, ... endpoints upstream? Since the proxy already revokes these bad certificates, the upstream traffic should be protected. We should be able to revoke any other bad certs in the the future as well.
show comments
AnkitGuptaTruth
The needful is complete
childintime
1. So there was no certification of the certifiers?
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
show comments
kyleomalley
Question: what about the other trusted roots? Has anyone tested them?
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
show comments
TazeTSchnitzel
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
show comments
jesuswasjew
This does not look like blunder; more like espionage. The bigger guys are throwing emudra under the bus.
show comments
russfink
> One of eMudhra's certificate authority private keys is the number 4.
Predicting more LAN devices come pre-installed with a variety of private VPN options and an option to route all traffic from specific devices through that.
zkmon
Anything to update/check for Macs running on various versions of the OS?
show comments
Gabrys1
This has a big upside: I can now MITM any Android app / IOT device without any suspicious set up on the device? (given it'll run on the unupdated OS and that cert revocation is not ON).
> recovered all of them from their public certificates on my laptop just now, and it took less than a second.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
show comments
hypfer
This is not a good write-up. Yesterday's discussion did contain better data, less self-Promotion and actually asked why it happened, instead of just saying "number small".
megous
Well, so what now? It's not like I have these in my system CA store, they're just intermediaries cross-signed by sectigo.
show comments
dbcooper
All the numbers were under 384. Surely they couldn't have ...
show comments
unsupp0rted
Never attribute to malice what can be explained by ignorance?
In this case I wonder if this was an intentional wide open doorway to fraud
show comments
yoyohello13
I love how this article explains multiplication... very carefully.
bandrami
Shakti de. This should be firm-ending for them but I fear it won't be.
kristofferR
This is amazing! I've already been able to grab firmware images for two locked down ESP32-using devices that I struggled to jailbreak before.
I’ve tried asking Opus 5.5 but I don’t fully get the mechanics of this Certificate Authority stuff, wonder if someone can dumb it down here for me.
Here’s what I understand, every website sends some data encrypted by some key issued by CA and then the browser decrypts it first and then decrypts something in that message, to verify that Google.com, is google.com. I still don’t get why CA’s even exist, not sure what they are solving and how they’re doing it.
show comments
mitxela
From the author of "Passkeys are not a trap", and written by Claude from the looks of it...
show comments
koolba
What the chances there’s another CA key out there with something like unix time as the key?
> and no TLS certificates chaining to these CAs ever showed up in CT
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
show comments
sylware
The CA concept itself is flawed, unless normal users were able to cherry pick the CA they do trust, dream. And even with that, they must keep in mind that many authorities and/or mafias have very probably rogue certificates for browser invisible man-in-the-middle.
show comments
jesuswasjew
My izzat is down right now.
AlexITC
Another very unfortunate even next to the php, fun times we are living in.
naabozaurus
hey, at least it was easy to remember...
show comments
m3kw9
This has to be a backdoor planted by hackers, mess with the key gen, say is all good. Must be known since issuance.
sscaryterry
I wouldn't be surprised if we learn in the near future, that this was deliberate.
new email from wayne, who is the original reporter:
"I've had more than a few emails asking on how this was discovered. The simple answer is: https://github.com/google/paranoid_crypto
Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...
I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.
So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far."
https://groups.google.com/a/mozilla.org/g/dev-security-polic...
In retrospect, having 100 trusted certificate authorities might have been excessive.
> It's fortunate that the steps required here aren't particularly complicated for the devices you can update, and the advice essentially boils down to 'update them'. The problem is the devices you can't update or update easily.
> Update everything that ships a CA bundle: your OS ca-certificates package, certifi, Node, Homebrew, and rebuild your container images once the base images pick up the change.
> Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
Okay hear me out. People are complaining about unpatcheable IOT device and thats indeed concerning. But can’t we use the bad keys to generate seemingly value certificates that can be used to jailbreak these devices?
EDIT: seems its already happening? https://x.com/otomir23/status/2112697830687047918
Related: https://news.ycombinator.com/item?id=50166579
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
"Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh."
This statement is more discerning than anything else. It raises question about why this certificates exists in first place if not deployed since 2025. Is it deliberate attempt to do compromising of system?
In recent times, Indian Government is becoming quite rogue and don't follow the said procedures. So, it might be related to that as well.
Of COURSE it's easy to crack, 4 isn't even prime!
For all that DNSSEC is crap, DANE would at least mean that a domain is only vulnerable to failures of the authorities relevant to the domain.
Meanwhile there are two less invasive changes that really ought to happen:
1. A clean way for things like curl and Python to start checking CT logs like Chrome does.
2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.
My oven (which has a camera and WiFi, don't ask, it's a great oven otherwise and doesn't exist without WiFi) received a software update this morning. I can't help but wonder if it's related.
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
I will say, there’s something almost reassuring when something goes boom that badly and the story is really silly. It’s like [horrific human-caused disaster] but it’s because of a Three Stooges episode.
Two more things to note about impact assessment: Flatpak uses the selected runtime's baked-in trust store (I think), so any apps may be susceptible even if you update the system package. Containers also don't inherit the host's trust store and use the one from the base image.
Quick question for the crypto experts. I thought that the goal of a true random number generator was that all values between 0 and MAXCOUNT are equally likely, and therefore all private keys between those values are equally likely. Is this not true? If people are going to attempt to brute force your key, don't you want the floor to start at 0? If the floor is higher, won't the brute force start higher too?
For those running Ubuntu, the following page tells you what to do. It's two commands:
https://ubuntu.com/blog/emudhra-ca-compromise-fixes-availabl...
Maybe they are a CIA front like CryptoAG
This issue is highlighting a few things for me:
* It's absurd that Python, Go, or Node need their own certificate stores that need separate updates. (Probably OK for browsers because they seem very on top of updating them without user intervention.)
* This issue is especially bad when you consider deployment through containers, docker, etc. More parallel copies of vulnerable certificate stores. With docker volumes you could mount the host's certificates into the containers and get "update once" behavior but I doubt people are doing this.
* It wouldn't be too hard to implement CRLs against the OpenSSL certs as a script that runs from cron. I might end up doing this.
Someone used the Dilbert random number generator. https://www.random.org/analysis/
I reckon that was an attempt to fend off the enemy. "Everyone expects us to set 196 bits of entropy, but you know what they won't expect? A single byte!"
I wonder how someone stumbled upon this - maybe leaked by someone inside eMudhra?
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
Related ongoing thread: Your MCU Likely Escaped the eMudhra Intermediate CA Compromise - https://news.ycombinator.com/item?id=50183280
Previously: eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (458 comments)
That's some criminal negligence right there.
8 bits is crazytalk!
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
I'm wondering how many other private keys might be cropped to 32, 64 or 128 bit and much weaker than we think. Seems like nobody tested it yet. Otherwise the 8 bit would've been found within minutes.
It feels like they chose the private keys by hand.
>> "These roots and issuing CAs have gone through independent audits for two years in a row and have been in browser trust lists since mid-2025".
the Audit part is scary. The same audit process might have cleared many other stuff.
https://www.einpresswire.com/article/951151580/emudhra-state...
I thought CAs automatically filtered out really low keys. There's a great Suckerpinch video (https://youtu.be/M1si1y5lvkk) about trying to purposely make the least secure HTTPS page possible, and Tom initially tried to choose a laughably-low number as the key, but the CA automatically rejected it.
After my shock and anger subside, I can think more clearly now. I see many have mentioned using this to perform MITM on the IoT devices.
On the other hand, can we not utilize that to also protect the IoT devices? Can we not create a MITM proxy on our own network that proxies all of our IoT devices's traffic and then forwards them to the trusted HTTPS, MQTTS, ... endpoints upstream? Since the proxy already revokes these bad certificates, the upstream traffic should be protected. We should be able to revoke any other bad certs in the the future as well.
The needful is complete
1. So there was no certification of the certifiers?
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
Question: what about the other trusted roots? Has anyone tested them?
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
eMudhra explanation : https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
This does not look like blunder; more like espionage. The bigger guys are throwing emudra under the bus.
> One of eMudhra's certificate authority private keys is the number 4.
https://imgs.xkcd.com/comics/random_number.png
Predicting more LAN devices come pre-installed with a variety of private VPN options and an option to route all traffic from specific devices through that.
Anything to update/check for Macs running on various versions of the OS?
This has a big upside: I can now MITM any Android app / IOT device without any suspicious set up on the device? (given it'll run on the unupdated OS and that cert revocation is not ON).
Test your browser and update your system's certificates: https://emudhra.we-have-a-problem.com/
> recovered all of them from their public certificates on my laptop just now, and it took less than a second.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
This is not a good write-up. Yesterday's discussion did contain better data, less self-Promotion and actually asked why it happened, instead of just saying "number small".
Well, so what now? It's not like I have these in my system CA store, they're just intermediaries cross-signed by sectigo.
All the numbers were under 384. Surely they couldn't have ...
Never attribute to malice what can be explained by ignorance?
In this case I wonder if this was an intentional wide open doorway to fraud
I love how this article explains multiplication... very carefully.
Shakti de. This should be firm-ending for them but I fear it won't be.
This is amazing! I've already been able to grab firmware images for two locked down ESP32-using devices that I struggled to jailbreak before.
Bugzilla bug in question:
https://.mozilla.org/showbug.cgi?id=2083449
Man in the middle just for the love of the game
https://xkcd.com/221/
I’ve tried asking Opus 5.5 but I don’t fully get the mechanics of this Certificate Authority stuff, wonder if someone can dumb it down here for me.
Here’s what I understand, every website sends some data encrypted by some key issued by CA and then the browser decrypts it first and then decrypts something in that message, to verify that Google.com, is google.com. I still don’t get why CA’s even exist, not sure what they are solving and how they’re doing it.
From the author of "Passkeys are not a trap", and written by Claude from the looks of it...
What the chances there’s another CA key out there with something like unix time as the key?
Someone else has published usable .key files here: https://github.com/Fluepke/emudrahahahahaha
> and no TLS certificates chaining to these CAs ever showed up in CT
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
The CA concept itself is flawed, unless normal users were able to cherry pick the CA they do trust, dream. And even with that, they must keep in mind that many authorities and/or mafias have very probably rogue certificates for browser invisible man-in-the-middle.
My izzat is down right now.
Another very unfortunate even next to the php, fun times we are living in.
hey, at least it was easy to remember...
This has to be a backdoor planted by hackers, mess with the key gen, say is all good. Must be known since issuance.
I wouldn't be surprised if we learn in the near future, that this was deliberate.