A Certificate Authority Just Got Caught Using a Private Key of 4

Author: Better Stack · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: A Certificate Authority Just Got Caught Using a Private Key of 4 · Channel: Better Stack · 07:45 · Watch on YouTube

Topics: Cybersecurity and software security

Summary

Eight eMudhra intermediate certificate keys trusted by major browsers and operating systems were found to have extremely weak private values, including one that was simply 4. A researcher demonstrated that all eight keys could be recovered in under a second, after which browsers and other software began blocking them. Browser protections limited the risk, but many non-browser tools and devices do not consistently check certificate transparency logs or revocation. The incident highlights the importance of verifying generated keys and treating mismatched signatures as an emergency, and the video recommends updating CA packages and rebuilding container images.

Key points

A researcher reported that the private keys for eight eMudhra intermediate certificates were compromised; six were TLS issuing CAs and two were code-signing CAs.
The keys were P-384 elliptic curve keys, but their values were only a single byte after 47 zero bytes.
The eight private key values were 4, 56, 66, 115, 155, 156, 230, and 237, and could all be recovered in under a second.
According to eMudhra’s incident report, a script used during a changed key ceremony created a second weak key pair on its hardware security module, and the wrong pair was selected.
In June 2025, invalid signatures on eMudhra’s revocation lists were an earlier warning; the lists were re-signed with the weak keys rather than investigated.
The video says no certificates from the intermediates appeared in certificate transparency logs, which helped protect browser users, but many other clients do not check those logs or revocation.
A researcher demonstrated that curl, Python, and node accepted a forged api.stripe.com certificate on the Linux and Mac OS machines he tested.
The video recommends updating CA certificates, bumping certify to 2026.10.19 and Go to 1.27.3 if used, rebuilding container images, and testing with curl.
The key lesson is that valid cryptographic structure does not guarantee strong randomness; organizations need processes to verify that the certificate contains the intended key.

Chapters

Start	Chapter	Summary
00:00	The private key of 4	The video introduces the eMudhra incident and explains how a researcher reported eight compromised intermediate certificate keys.
01:33	How the weak keys were recovered	The presenter explains why the tiny private key values were easy to brute-force and how a key-generation process led to the mistake.
03:37	Browser protections and wider risks	The video contrasts browser protections with the risks to command-line tools, CI systems, and devices that may not receive updates.
05:10	Remediation and lessons	The presenter covers software responses, the need to verify generated keys, and steps viewers can take to update and test their systems.
06:44	Testing whether your client is safe	The video gives a curl test and closes by emphasizing the potential impact of weak certificate keys outside browsers.

Quotes

turned out to be literally just number four. — 00:00

all eight keys come back in under 1 second. — 02:05

browsers are fine. — 03:37

cryptography can’t warn you when your randomness is missing. — 06:13

if you get a certificate error, then your client is safe. — 06:44

Concepts and entities

eMudhra, Sectigo, Wayne, Scott Helm, P-384, certificate transparency logs, Cloudflare, Go

Full transcript (original language)

00:00 There’s this old XKCD comic out there where a function called get random number just returns the number four chosen by a fair dice roll. Well, this week certificate authority basically shipped that comic into production. One of eMudhra’s CA private keys, which was trusted by every major browser and operating system, turned out to be literally just number four. So, in this video I’ll explain how that happened, why nobody noticed this for 17 months, and why your browser’s probably fine,

00:31 but your CI pipeline might not be. There’s a lot to go over, so let’s dive into it. So, on October 17th, a security researcher named Wayne reported to Apple, Google, Microsoft, and Mozilla that the private keys for eight eMudhra intermediate certificates were compromised. Six of them were TLS issuing CAs, and two were code signing CAs. All of them were created back in April 2025, and then also signed by

01:02 Sectigo, which is a much bigger and older certificate authority. And to prove it, Wayne signed the message “We have a problem here” with every single one of those keys. And Chrome and Firefox blocked the certificates within hours, and Apple and Microsoft followed over the next three days. But to understand why this is so bad, you need to know how these keys work. These are elliptic curve keys on the P-384 curve. The private key is just a number called D, and the public key in the

01:33 certificate is D multiplied by a fixed point on the curve called G. Going from D to the public key is easy, but going backwards is considered impossible as long as D is a random 384-bit number. That gives you roughly 10 to the power of 115 possibilities. So, nobody is ever going to brute force it. But eMudhra’s keys were 47 bytes of zeros followed by just one single byte. A byte only has 256 possible values, so

02:05 cracking it just means computing 1 * G, 2 * G, 3 * G, and so on and so forth, and stopping when the result finally matches the certificate. So, I grabbed the certificates that Mozilla attached to its announcement and wrote a tiny Python script that does exactly that. And as you can see, all eight keys come back in under 1 second. And their values are 4, 56, 66, 115, 155, 156, 230, and 237. And the scary part is that nothing about

02:36 these certificates looks broken because a key of four still produces a perfectly valid point on the curve and passes every structural check. So, how does a certificate authority end up with a private key of four? Well, according to e-Mudhra’s incident report on Mozilla’s bug tracker, they changed their usual key ceremony to test exporting keys, and the bug in that script created a second weak key pair on their hardware security module. The two key pairs had similar

03:07 names, and someone picked the wrong one when generating the certificate requests. But, there were warning signs much earlier. In June 2025, Sectigo reported that e-Mudhra’s revocation lists had invalid signatures. That happened because e-Mudhra signed them with the original strong keys which didn’t match the weak keys in the certificate. And instead of investigating why, they re-signed the list with the weak keys. One commenter on Hacker News called that the line between an honest mistake and gross

03:37 negligence. And they might have a point because basically, it means all this whole thing could have been caught 16 months ago, but unfortunately, here we are. Now, the good news is that browsers are fine. No certificates from these intermediates ever showed up in certificate transparency logs, which are the public logs that every trusted TLS certificate has to be recorded in. And Chrome, Firefox, and Safari all reject certificates that aren’t logged. But the bad news is that almost everything outside the browser doesn’t check those

04:08 logs or revocation at all. Tools like curl, Python, node, go, and git trust whatever CA bundle is sitting on disk. Security researcher Scott Helm managed to forge a certificate from api.stripe.com and on every Linux and Mac OS machine he tested, curl, Python, node all accepted it. Think about what that means for all the installation scripts piped into bash or all the CI runners holding cloud credentials and server to server API

04:39 calls. And even the browser fix wasn’t perfectly consistent because people on Hacker News reported Firefox on Android loading the attack test sites with no warnings at all. And for smart TVs, routers, and other devices that never get updates, these certificates will stay trusted until they expire in July 2039. Yikes. And you know what’s even worse? According to our stats, 80% of the people watching this video are not subscribed to our channel. So if something like this happens again in the future, you don’t want to miss out on

05:10 it. So hit that subscribe button, folks, so you get updated with the latest security breakdowns. But getting back to our story, so basically the post cleanup has been quite huge. Cloudflare shipped updates to its warp client, its 1.1.1.1 app, and also their tunnel software all on October 20th and said it found no signs of exploitation on its services. And go pushed an emergency release that blocks these eight intermediates directly in its standard library.

05:41 Mozilla is removing eMudhra’s root entirely and Chrome will follow on October 27th. That gives eMudhra about a week to move roughly 30,000 certificates to another hierarchy before these sites start breaking. And the timing couldn’t be worse for them because only a month ago Mozilla’s public discussion on accepting eMudhra’s own root had wrapped up with the CA slated for approval. People in the Hacker News thread are comparing this to DigiNotar, the Dutch certificate authority that went bankrupt

06:13 after its 2011 breach. So, I guess the writing is on the wall now for them. But, what is the big lesson here? Well, this just goes to show you that cryptography can’t warn you when your randomness is missing. A key of four passes every check, so the real protection has to be a process that confirms that that key in the certificate is the one you actually meant to generate. And security teams need to treat mismatched signatures as an emergency. But, to protect yourself, here’s what you should do immediately.

06:44 Update your CA certificates package, bump certify to 2026.10.19, and if you’re using Go, bump it to 1.27.3, and rebuild your container images. Then, run curl against dvg3b.emudhra.wehaveaproblem.com, and if you get a certificate error, then your client is safe. So, there you have it, folks. That is how an old programming joke turned out to be true. Life sometimes does indeed really

07:14 imitate art, I guess, but not in a good way. So, imagine how bad this disaster is. For 17 months, anyone could have used these keys to pretend to be any website, and most software outside your browser would have believed them. But, thankfully, finally, we’re fixing this issue. And let me know in the comments if you’ve had to patch anything because of this, and if you have any tips for developers on how to stay safe in these situations. And if you like these types of technical breakdowns, please let me know by smashing that like button underneath the video. And also, don’t

07:45 forget to subscribe to our channel. This has been Andrus from Better Stack, and I will see you in the next videos. >> [music]