What happened
On 17 October 2026, Mozilla and Google distrusted eight intermediate certificates operated by eMudhra, one of India's licensed certifying authorities. Apple followed on 19 October and Microsoft on 20 October. The cause was elementary. Researcher Scott Helme showed that the P-384 private keys behind the certificates were single-byte numbers between 4 and 237. A proper P-384 key is a random 384-bit value. These could be brute-forced in at most about 255 steps, in under a second on a laptop.
The certificates were created in April 2025, so the keys were effectively public for about 17 months. Six of the intermediates were for TLS websites and two for code signing. CERT-In's advisory CIAD-2026-0050 attributes the failure to the key-generation process, not to the algorithm. It says eMudhra revoked the eight intermediates on 18 October. As of 21 October, the disclosures it cites did not confirm malicious use.
On 22 October eMudhra announced it would leave the global SSL/TLS business. It said that business was about 1% of its revenue. Its Indian digital signature, eSign and enterprise services continue.
The strongest case for the official reaction
MeitY's defensive posture has a real basis. The company says no end-entity certificates were issued from the affected intermediates. CERT-In reports that Google found no TLS certificates chaining to them in Certificate Transparency logs before they were blocked. The business involved is marginal. Indian signing certificates, which underpin tax filings and company registrations, sit in a separate hierarchy that the advisory says is unaffected. MediaNama reports that MeitY said the Controller of Certifying Authorities (CCA) "remains completely unaffected by this incident" and that some social media accounts were spreading fear. A government that treats every vendor bug as a national emergency would chill the market it wants to grow.
That argument is right on blast radius and wrong on accountability. A claim of no known exploitation is weaker evidence than it sounds when the keys were guessable by anyone for 17 months. Certificate Transparency catches mis-issuance that gets logged. It cannot rule out a forged certificate that was never logged and was used only against a targeted victim.
Where the system worked, and where it did not
The browser root programs did what they exist to do. A researcher disclosed, Mozilla and Google blocked the certificates within days, and Apple and Microsoft followed within three days. None of this required legislation. It is a good example of a private, technically competent trust system policing itself faster than any statute could. Pro-innovation policy should preserve that mechanism, not try to duplicate it with state-run trust lists.
But the same speed shows the gap on the Indian side. The CCA licenses India's certifying authorities, and its own page lists 14 of them issuing Class 2 and Class 3 certificates to the public. The page points to key-generation and storage requirements in Section 6.1.1 of the Certificate Policy for India PKI. A one-byte private key could not have been produced by a process that met any reasonable reading of those requirements. Yet five days after the incident the CCA had made no public statement. The question is no longer whether browsers will distrust a bad CA. They will. The question is how an audited, licensed CA generated these keys, and whether the audits that should have caught it examine key-generation ceremonies at all.
Section 30 of the Information Technology Act, 2000 requires certifying authorities to follow security procedures. If the regulator does not say whether that duty was met, the licence tells relying parties little.
Why exit is not accountability
eMudhra's own explanation cites rising data-sovereignty and compliance costs, free certificates from large issuers, and disproportionate social media scrutiny. Those pressures are real, and a 1% revenue line is a rational thing to drop. But a commercial exit does not answer the public-interest questions. Helme reports that eMudhra attributed the failure to a bug in a key-generation script and a naming mix-up that led to the wrong keys being used. That is plausible, but it comes from the company, and the root-cause report owed to the browser programs will be the first detailed account. The other 13 licensed authorities also run key ceremonies, and nobody outside the CCA knows how they were checked.
A proportionate response would not be a new licensing regime or a mandate to use only domestic roots. Forcing Indian websites onto a government-run root would create precisely the single point of failure this incident shows is dangerous. A better set of steps is narrower and cheaper:
- Publish the CCA's findings. State what the audit trail showed for the April 2025 key generation and why it was not caught.
- Require independent key-generation verification. CERT-In already recommends this. It should be an auditable licence condition, not advice.
- Adopt public incident reports. Browser programs publish root-cause analyses. A licensed Indian CA should be held to the same standard of disclosure.
- Review the other 13 authorities. A short, published confirmation that their key ceremonies meet the Certificate Policy would restore more trust than any denial.
The takeaway
India's web security was not damaged by this incident so much as by the response. The technical failure was caught by outsiders and contained by browser vendors in days. What remains untested is whether India's licensing and audit apparatus can explain a failure of this kind. Calling the criticism fear mongering, while the licensing body stays silent, invites the opposite of the confidence the government wants. Transparency would cost the regulator very little and would protect an ecosystem that India's digital-signature economy depends on.