Indian CA Sets Private Key to 4: HTTPS Trust System Exposes Another Critical Flaw

A Single Number Four Breaches the Foundation of HTTPS Trust

According to disclosures by the YouTube tech commentary channel Lunduke Journal, an Indian root certificate authority (CA) named eMudhra set the private keys of eight of its intermediate certificates to extremely simple numbers—one of them was literally "4." Anyone with basic cryptographic knowledge could guess this key in seconds and then forge HTTPS certificates for any domain.

Even more unsettling is the timeline: these weak keys were issued as early as April 2025, but they were not discovered and publicized until October 17 of the same year by an anonymous security researcher using the alias "Wayne." For a year and a half, attackers could have used these private keys to issue seemingly legitimate HTTPS certificates while the outside world remained completely unaware.

Root CA and Intermediate Certificates: In the PKI (public key infrastructure) system, the root CA is the starting point of the trust chain, and its root certificate is pre-installed in browsers and operating systems. To reduce the risk of exposing the root private key, root CAs usually do not directly issue end-entity certificates; instead, they issue intermediate certificates (Intermediate CA), which then issue website certificates. This way, if an attacker compromises only an intermediate certificate, the root CA can revoke it to limit the damage. But the private key of an intermediate certificate also has issuance capability. Once it is as weak as "4," an attacker can forge certificates for any domain, and because the trust chain is complete, browsers will not raise an alert.

Certificate Transparency (CT): This is a public audit log system that requires every certificate issued by a CA to be submitted to public CT logs, and browsers can check whether a website certificate has been recorded. CT can detect anomalous issuance (such as forged certificates), but only if the CA honestly submits them. If a private key has already leaked, an attacker can issue certificates on their own without submitting them to the logs; CT can only trace afterward and cannot stop the attack.

The Essence of the Vulnerability: Not a Matter of Encryption Strength, but a Failure of the Trust Anchor

Many people's first reaction is, "Wasn't the encryption algorithm strong enough?" This incident shows precisely that the problem is not the bit length of AES or RSA, but the trust anchor of the entire PKI system. Root certificate authorities are the starting point of the entire HTTPS trust chain, and browsers and operating systems trust certificates issued by them by default. Once the private key of a root CA or its subordinate intermediate certificate leaks or is too simple, all downstream systems that rely on that trust chain become accomplices.

According to the Mozilla Bugzilla discussion shown by Lunduke in the video, initial estimates suggest about 30,000 certificates need to be migrated, about 97% of which were automatically issued via the ACME protocol. This means a large number of sites may unknowingly be using a certificate chain that can be forged.

After learning of the vulnerability, Mozilla took three days to update its certificate trust list (NSS), which is relied upon by many open-source projects such as curl and Python. During that three-day window, any system relying on that list was at risk. As of now, systems such as macOS have still not completed the update, and the tail impact of the vulnerability is far from over.

ACME Protocol: The Automatic Certificate Management Environment is an automation protocol promoted by CAs such as Let's Encrypt, allowing servers to automatically request, validate, and renew certificates. In this case, about 97% of affected certificates were automatically issued via ACME, meaning a large number of sites were connected to the problematic certificate chain without knowing it. ACME improves efficiency, but it also amplifies the spread of misconfigurations—once an error occurs at the CA level, automated processes can rapidly propagate weak certificates.

NSS (Network Security Services): A network security services library maintained by Mozilla that contains the root certificate trust list shared by browsers and many open-source software programs. Tools such as curl and Python rely directly on NSS's trust store. Delays in Mozilla updating NSS directly cause these tools to continue trusting contaminated intermediate certificates during the window.

Why This Is a "Design-Level" Flaw

In the program, Lunduke reiterated his view from years ago: the CA system on which HTTPS relies is essentially "security based on trust," not "security based on mathematics." There are dozens of root certificate authorities worldwide, located in different legal jurisdictions and influenced by different governments or companies. It is logically impossible to require every one of them and every link in the chain to avoid low-level mistakes.

He compared this incident to "setting your suitcase combination to 12345"—and setting the private key to 4 is several orders of magnitude lower than that. More critically, the system is designed so that a mistake by a single CA can affect the whole world, while the outside world can hardly audit each CA's internal operations. This structural information asymmetry is the root cause of recurring problems.

Some security researchers once created a forged certificate for a google.com subdomain as a proof of concept, demonstrating how low the attack threshold is. This is not an isolated case, but a concentrated exposure of the long-standing systemic risk in the CA system.

The Trust Model of Public Key Infrastructure (PKI): PKI binds identities to public keys through a CA hierarchy, and its security depends on the assumption that "all CAs strictly protect their private keys." But there are dozens of root CAs worldwide, located in different jurisdictions and influenced by different governments and commercial entities, making audits difficult to extend to internal operations. This "trust transfer" model is essentially a technicalization of social trust, not a mathematical proof. A single CA's mistake (such as setting a private key to 4) spreads down the trust chain to all downstream systems, and end users cannot choose which CAs to trust, creating a structural information asymmetry.

Remediation Dilemmas and Subsequent Impact

Simply "upgrading the encryption algorithm" cannot solve this type of problem. As long as human error or malicious backdoors exist in root CA private key management, the attack surface will always remain. Feasible mitigation measures include mandatory auditing of Certificate Transparency logs, regular external audits of CA organizations, and shortening certificate validity periods to reduce the impact window of single-point failures.

For developers and operations teams, the most practical action right now is to check whether their own certificate chains involve intermediate certificates issued by eMudhra and to update system trust stores in a timely manner. For ordinary users, this incident reminds us that the "lock" in the browser address bar only means the connection was signed by some CA; it does not mean the other party's identity is absolutely trustworthy.

HTTPS is still the most feasible transport security solution available today, but its security is built on continuous auditing and timely response, not one-time trust. When a CA can set its private key to 4, the entire ecosystem needs to re-examine the cost of "default trust."

One-line Summary

An Indian CA set an intermediate certificate private key to "4," exposing structural flaws in the HTTPS trust system.

Paragraph Summary

Indian root certificate authority eMudhra set the private keys of eight intermediate certificates to extremely simple numbers, one of which was "4," allowing anyone to easily forge HTTPS certificates for any domain. These weak keys were issued in April 2025 but were not discovered until October 17 of the same year by an anonymous researcher, with a latent period of a year and a half. After learning of this, Mozilla took three days to update its trust list, while systems such as macOS remain unfixed to this day, and about 30,000 certificates need migration. The incident reveals that the CA system HTTPS relies on is essentially "security based on trust" rather than "security based on mathematics," and a single CA mistake can affect the whole world. Simply upgrading encryption algorithms cannot solve this; systemic improvements such as Certificate Transparency auditing and shorter validity periods are needed.