The CA Whose Private Key Was Literally "4": How One Certificate Incident Left curl Defenseless

A site that browsers had long since blacklisted was still happily served up by curl—no warning, no blocking, not even a hint. This isn't someone misconfiguring their environment; it's the one link in the trust chain that should never fail failing in the most absurd way possible.

Tech YouTuber ThePrimeagen reproduced this scenario in a video: Chrome flatly refused access, while the command-line tool curl sailed right through. He called it "I didn't even know I was being man-in-the-middled." Drawing on his demonstration, this article traces the ins and outs of the incident and the structural cracks it exposes in the HTTPS trust system.

What HTTPS Actually Protects

To grasp the severity of this incident, we first need to return to the fundamentals of the internet. The early internet ran on HTTP, with all data in plaintext—anyone who could intercept communication between you and a server could directly see what you were typing. It wasn't until people started sending banking passwords and personal information online that HTTPS became essential: it encrypts data packets so that even if an intermediary captures the content, all they see is unreadable gibberish.

But encryption only solves half the problem. Your request isn't "a single wire directly to the server"—it's forwarded hop by hop through multiple intermediate servers. If a node impersonates "google.com," your encrypted data is actually encrypted to this impersonator, which then decrypts it, forwards it, and retrieves the result—your password ends up in their hands. This is a man-in-the-middle attack (MITM).

Certificate Authorities: The Gatekeepers of Trust

To solve "am I actually connecting to the real google.com," the internet introduced certificate authorities (CAs). A CA vouches for the sites you visit with its own reputation: after confirming the other party's identity, it issues a certificate, and your system only needs to trust this group of CAs to indirectly trust all sites they've signed.

The problem is that there are only about 50 to 85 publicly trusted CA companies worldwide (ThePrimeagen cites Google's figure). This number is small, meaning any one of them making a mistake could affect the entire ecosystem—and this time, the one that stepped on a landmine was the Indian CA eMudra.

NIST P-384 is an elliptic curve cryptography (ECC) standard recommended by the U.S. National Institute of Standards and Technology (NIST), using elliptic curves over a 384-bit prime field. Compared with the traditional RSA algorithm, ECC offers shorter keys and higher computational efficiency at the same security strength, so it is widely used in TLS certificates, code signing, and similar scenarios. A P-384 private key should theoretically be a 384-bit random integer (i.e., between 1 and 2^384-1), and its randomness directly determines security. If the private key generation process has flaws—such as a failed random number generator or insufficient entropy—predictable private keys can result, rendering the certificate system useless.

The Heart of the Incident: Eight Private Keys, All "4"

According to the video, eMudra generated a batch of elliptic curve keys conforming to the NIST P-384 specification during a key signing ceremony. By design, private keys should be extremely long large numbers, but these eight keys' private keys turned out to be 47 bytes of zeros—roughly equivalent to something like "4" in familiar terms. The joke at the video's opening about "your favorite number between 1 and 2 to the 382nd power" is precisely satirizing this.

A guessable private key is as good as no private key at all. Anyone who possesses this "4" can impersonate any site in the name of these certificates, and systems relying on these CAs will accept it wholesale.

Timeline: Browsers Reacted Fast, System Trust Stores Reacted Slowly

The disclosure process was quite efficient. According to the video, a researcher named Wayne used a key-checking tool to scan certificates and discovered these eight anomalous EC keys in a disclosure database; by 6 p.m. that same evening, he had emailed the issue to Apple, Chrome, Microsoft, Mozilla, and eMudra itself. Chrome confirmed and pushed an update the same day, eMudra acknowledged the problem the same day, and most browsers completed remediation within 24 hours.

The real problem lay outside the browsers. Browsers update quickly, but system-level trust stores—such as ca-certificates.crt or cert.pem—do not sync automatically. A large number of tools including curl, git, Python, Perl, Ruby, and OpenSSL rely on precisely this file. As long as these tools don't check the revocation status of eMudra-related certificates, the window for man-in-the-middle attacks remains wide open.

ThePrimeagen's demonstration is therefore all the more striking: a site blocked by browsers could still be fetched normally by curl. This means any "one-click install script" (curl | bash) could pull back tampered code without you noticing; likewise, an unupdated Node environment running npm install could introduce malicious packages, ultimately leading to API key leakage or even account bans for distillation attacks.

Certificate revocation is a key mechanism in the PKI system, used to invalidate a certificate in advance after its private key is leaked or it is mistakenly issued. Common methods include certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP). Browsers typically have built-in revocation checks or respond quickly by updating root certificate lists, but system-level trust stores (such as Linux's ca-certificates package or macOS's Keychain) update less frequently, and many command-line tools do not perform real-time revocation queries by default. This discrepancy causes certificates already blocked by browsers to still be considered valid in tools like curl, creating a security window.

The Overlooked Deeper Problem

The most alarming aspect of this incident is not that some CA made a mistake—CA errors are not rare in history—but the asymmetry of the fixes. Browser vendors have mature revocation mechanisms and rapid response processes, while the open-source toolchain and a large number of embedded systems, CI environments, and container images often rely on a certificate file that never changes for long periods. Security advisories go out, but those who actually need to update may not know.

Another underlying concern is traces of abuse. At the end of the video, an unavoidable question is raised: a nearly public private key existed for more than a year—it's hard to imagine it was never exploited. There is currently no public evidence of large-scale abuse, but "no evidence" and "it didn't happen" are two different things, and that is precisely why this incident is unsettling.

What to Do Now

There isn't much ordinary users can do, but developers can act immediately: update your operating system and the ca-certificates package, check the certificate store versions in your CI pipelines and container base images, and avoid using unverified curl | bash installation methods in production environments. As for the "rooting a smart speaker with a search engine" mentioned in passing in the video—that's another topic entirely, but it serves as the same reminder: any weak link in the trust chain can become someone else's entry point.

When the entire internet's encrypted trust is pierced by a single "4," what may truly need updating isn't just certificate files, but our assumption of "secure by default."