deniz.in

Markets

Weather

Loading weather

· via Hacker News – Front Page (native)

eMudhra exits global SSL/TLS certificate business after computable CA keys triggered browser blocks

eMudhra will withdraw from the global SSL/TLS certificate business after eight emSign intermediate CA keys, weakly generated during a 2025 key ceremony, were found computable from public certificates and blocked by browsers.

eMudhra exits global SSL/TLS certificate business after computable CA keys triggered browser blocks

eMudhra withdraws from global TLS

eMudhra Limited, the Indian digital trust company that sells certificates under the emSign brand, said on October 22, 2026 that its board has decided to voluntarily withdraw from the global SSL/TLS certificate business. The decision follows an incident in which the private keys for eight emSign intermediate CA certificates turned out to be computable from their public certificates — not stolen by an attacker, but derivable by anyone because they were generated with too little randomness.

According to eMudhra's announcement, chairman V. Srinivasan said the company revoked the affected CAs within 14 hours of discovery and disclosed the problem promptly. He maintained that no end-entity certificates were issued from the affected CAs, that no infrastructure was compromised and that no data was breached. He also framed the exit commercially: global SSL/TLS contributes roughly 1% of company revenue, compliance costs keep rising, several large players issue certificates for free, and the online scrutiny the incident attracted was disproportionate to the size of that business line.

What went wrong

A technical writeup on dev.to reconstructs the failure: a flaw in eMudhra's April 2025 key ceremony produced a second, weak set of keys alongside the intended ones, and the weak set is what ended up published to browser root stores. The eight affected intermediates span six TLS issuance profiles — domain, organization and extended validation — plus two code-signing profiles, issued through eMudhra BV in the Netherlands and eMudhra Inc in the United States. Per a list published by Mozilla cryptography engineer Dennis Jackson, each of the eight also exists as a duplicate certificate cross-signed by Sectigo under its AAA Certificate Services root.

Those weak keys sat in public root stores for roughly 18 months. A researcher, credited by Mozilla only as Wayne, demonstrated possession on October 17, 2026 by signing a message with each of the eight keys. Mozilla reproduced the key computation within two hours of receiving the report, researchers have since published all eight keys, and Mozilla and the Chrome Root Program formally confirmed the compromise on October 20.

Browsers moved within hours

The dev.to writeup documents the response timeline: Chrome pushed a CRLSet update blocking the six TLS intermediates 100 minutes after Wayne's report arrived on October 17, and because the block matched public keys rather than certificates, it also caught the Sectigo cross-signed copies. Mozilla pushed an OneCRL block to Firefox the same evening. Apple and Android followed on October 19, and Microsoft on October 20. Certificate Transparency limited browser exposure, since no TLS certificate chaining to the six web intermediates had been logged before the blocks landed. eMudhra has since revoked all eight certificates.

How the wind-down will work

According to the press release, eMudhra's G1 RSA roots will keep serving customers during the transition, affected customers will receive free replacement certificates from partners, and revocation and certificate-status services will run until every issued certificate has expired or been replaced. The company says it will finish its remaining commitments to the browser root programs, including a full root-cause report. Its other lines — digital signature certificates, eSign, enterprise PKI platforms, eSignature tooling and identity products — are unaffected.

The residual exposure

Browsers are largely covered; other software is not. The dev.to writeup notes that Go binaries, Python services relying on the certifi bundle and many other TLS clients neither check revocation nor enforce Certificate Transparency, so they keep trusting the chain until their code or root bundle changes. Released fixes include Go 1.27.3 and 1.26.10 (CVE-2026-111943), which requires rebuilding already-deployed binaries; Firefox 158.0.1 (CVE-2026-113470); NSS 3.131.1; certifi 2026.10.19; Rust webpki-roots 1.0.10; and a Homebrew ca-certificates update — all removing or rejecting emSign ECC Root CA - G3. Apple's root list still contains the Sectigo root behind the cross-signs, and the two code-signing intermediates sit outside browser blocklists entirely. Mozilla reportedly believes no other CAs are affected, and Chrome says it found no other instance of this failure mode in its store.

Discussion on Hacker News argued the episode points at weaknesses in how root programs approve and monitor CAs generally, rather than at any one company or country, and that real demand remains for an India-based certificate authority.

Why it matters

A certificate authority voluntarily leaving the global TLS market is rare, and the mechanics here are the uncomfortable part: a key-generation flaw made the keys recoverable by anyone from the day the certificates were published, with no intrusion to detect and no attacker dwell time to bound. The incident also maps where trust actually breaks — browsers with pushed revocation lists and Certificate Transparency requirements contained the damage within hours, while Go services, static root bundles and code-signing paths stay exposed until patched or rebuilt. Finally, it illustrates the economics squeezing smaller commercial CAs as free issuance dominates, concentrating web trust in fewer roots. For engineering teams, the actionable item is inventory: find the clients that skip revocation checking and rebuild them.

  • #tls
  • #pki
  • #security
  • #certificate-authorities
  • #browsers

Related posts