#emudhra

Read Time:3 Minute, 47 Second

eMudhra Limited, an Indian digital trust and certificate authority provider, has announced it will exit the global SSL/TLS certificate business entirely. The move follows the discovery that eight of its intermediate certificate authority certificates were issued using private keys weak enough for an outside researcher to recover almost instantly, a flaw that traces back to a key-generation ceremony eMudhra ran more than a year earlier.

A Key Weakness Fifteen Months in the MakingAccording to eMudhra’s own preliminary account, the problem originated in a key-generation ceremony held on April 30, 2025. A flawed script used during a key wrap and unwrap step generated a second, unintended set of weak keys alongside the correct ones. Because the labels on the weak keys resembled those of the legitimate ones, staff later used the wrong keys when generating certificate signing requests for eight intermediate CAs. The affected keys used the P-384 elliptic curve, but instead of the astronomically large random values P-384 is supposed to produce, the private key values came out under 256, making them trivial to reconstruct from the corresponding public key.

India’s national CERT, CERT-In, was explicit that the flaw sat in how the keys were generated, not in any weakness of the P-384 algorithm itself. Of the eight compromised intermediates, six supported general TLS certificate issuance and two were used for code signing. eMudhra has said none of the affected intermediates directly issued end-entity certificates, the kind that websites and applications actually present to browsers, which somewhat limits the blast radius.

From Discovery to Revocation in HoursThe weakness came to light on October 17, 2026, when a researcher using the handle Wayne demonstrated proof of control over all eight private keys. Mozilla independently reproduced the key recovery, confirming the generation flaw was real and exploitable. Google and Mozilla moved the same day to block the affected TLS keys and began the process of removing trust in the emSign ECC Root CA – G3 to protect browsers and clients that don’t reliably check intermediate certificate revocation status in real time.

eMudhra Chairman V. Srinivasan said the company revoked the affected certificates within 14 hours of the disclosure. CERT-In subsequently stated that, as of its October 21 update, public evidence had not confirmed any actual malicious exploitation of the weak keys, though the window during which a sophisticated attacker could have forged certificates was real regardless of whether anyone is known to have used it.

Why Exit the Business Entirely?eMudhra’s decision to abandon global SSL/TLS issuance rather than simply remediate the incident reflects as much business calculation as security concern. The company says the global certificate segment accounts for roughly 1% of its total revenue, a figure dwarfed by the compliance overhead, data-sovereignty requirements, and intensifying price competition from free certificate authorities that have steadily eroded margins in commercial TLS issuance for years. Srinivasan also pushed back on what he characterized as social media criticism disproportionate to the size of the affected business line, while acknowledging the incident raised legitimate questions about the company’s certificate issuance controls.

The Migration AheadeMudhra estimates approximately 30,000 certificates, separate from the eight compromised intermediates themselves, will need to migrate away from its global SSL/TLS infrastructure as part of the wind-down. The company says it will keep its G1 RSA root certificates operating to serve existing customers during the transition, offer replacement certificates through partners at no additional cost, and maintain revocation and status-checking services until all affected certificates either expire naturally or are replaced.

CERT-In’s advisory, tracked as CIAD-2026-0050, urges administrators not to assume the issue is confined to web browsers. It specifically recommends reviewing certificate bundles embedded in applications, containers, and network appliances, locations where an expired trust relationship can quietly break functionality long after browsers have already adjusted. Chrome’s root-store change affecting the emSign root is expected to reach most devices by October 27, 2026.

What Organizations Relying on eMudhra Certificates Should DoInventory every system, application, container, and network device that references an eMudhra-issued or emSign-rooted certificate, not just public-facing websites.

Replace certificates proactively through eMudhra’s partner migration path rather than waiting for a browser trust change to break production services.

Update browsers and trust stores on managed devices to ensure the upcoming root-store changes are reflected promptly.

Treat this as a reminder to track certificate issuer concentration risk across your infrastructure, since a single CA’s operational failure can cascade into unplanned migration work.

Because eMudhra is in the news, I am sharing a screenshot of a footer of an email I once received from them in reply to my query about my PAN card (a government-issued tax identity and card). #eMudhra

Read Time:3 Minute, 12 Second

Browser makers and software maintainers are rapidly withdrawing trust from eight eMudhra intermediate certificate-authority certificates after a researcher demonstrated control of their private signing keys. Because the intermediates connect to roots accepted by major platforms, clients that still trust the affected chains could potentially accept fraudulent certificates as genuine.

The researcher, identified publicly as Wayne, reported the issue to certificate root programs on October 17, 2026. To prove possession without publishing the secrets themselves, the researcher signed a short message with each compromised private key. The corresponding certificates, public keys and signatures were released so independent reviewers could verify the result with standard cryptographic tools.

Why an intermediate CA key mattersA website certificate is usually trusted through a chain: the site certificate is signed by an intermediate authority, which ultimately links to a root embedded in a browser, operating system or application. Possession of an intermediate’s private key may allow an attacker to issue new certificates that vulnerable clients accept under that chain.

That capability does not automatically place an attacker inside a user’s network. But when combined with the ability to intercept or redirect traffic, a forged certificate could support convincing website impersonation and potentially allow encrypted traffic to be read or modified. This is why certificate-authority incidents demand ecosystem-wide action rather than a fix on a single web server.

The public evidence confirms signing capability, not the cause of the exposure. It does not establish that the keys were recovered through a rapid cryptographic break, despite claims circulating online, and it does not prove that forged certificates were used against end users. How the keys became accessible remains publicly unresolved.

Browsers moved quickly to block the chainsMozilla received the report at 20:06 UTC on October 17 and completed a OneCRL blocklist rollout less than three hours later. Standard Firefox configurations could receive that protection without a conventional browser upgrade or restart. Chrome reportedly blocked the certificates the same day, Apple followed on October 19, and Microsoft deployed protection on October 20. eMudhra has revoked the affected intermediates as well.

Mozilla also shipped Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 for environments where settings might prevent OneCRL delivery. NSS 3.131.1 removes the associated signing root from the trust list used by other software. Additional fixed trust bundles include Go 1.27.3 and 1.26.10, Python certifi 2026.10.19, and Rust webpki-roots 1.0.10. Updates for some other ecosystems were still pending when the incident response information was reviewed.

Application trust stores are the long tailCertificate revocation alone is not universal protection. Some programs do not check revocation status reliably, cannot receive browser-maintained blocklists, or ship a private copy of trusted roots. A fully updated browser may reject the affected chain while a command-line client, container image, embedded device or older application continues to accept it.

Update browsers and operating systems across managed endpoints.

Inventory runtimes, containers and applications that bundle their own CA files.

Upgrade language-specific trust packages and rebuild images that pin older bundles.

Use the public incident test chains to check important clients for rejection.

Escalate any unexpected acceptance or suspicious certificate observations to the security team.

Manual removal of roots should be reserved for experienced administrators because trust-store changes can break legitimate connections. Where vendors have published supported releases, those updates provide a safer and more auditable remedy.

The incident illustrates a recurring weakness in public-key infrastructure: emergency browser controls can protect mainstream users quickly, while fragmented software dependencies take longer to converge. Organizations need an inventory of certificate bundles just as they need an inventory of vulnerable libraries. Without it, defenders may patch the visible browser fleet and overlook the services that perform sensitive machine-to-machine connections.

truly a wild time to be alive when the cryptography world is split between those worried about quantum computers and those whose private key is “4”

http://arstechnica.com/security/2026/10/the-internet-goes-on-high-alert-after-discovery-of-8-compromised-tls-certs/

#eMudhra