eMudhra Admits 'The Flaw Was Ours': Is Your Terminal Still Trusting It?

eMudhra admits a script error left eight CA keys weak. Browsers are safe, but macOS curl, git and bundled CA stores may still trust them. Here's what to fix.

Cobalt blue TheTechLane cover with the TL logo, the headline The flaw was ours. Is your terminal still trusting it?, and a certificate chain of three cards with the middle intermediate card cracked open

Indian certificate authority eMudhra has publicly apologised for a key-generation blunder that let anyone recover the private keys of eight of its intermediate CAs, keys that could have been used to forge a trusted HTTPS certificate for any website. "The flaw was ours," the company wrote on October 26, just as Chrome gets ready to drop the root behind those keys on Tuesday.

Here's what you need to know:

  • A researcher showed on October 17 that the private keys of eight emSign G3 intermediate CAs could be recovered. Six of them issue TLS certificates.

  • eMudhra now blames "a script error" and says the intermediates were revoked within 14 hours of confirming the issue, with no publicly trusted end-entity certificates issued from them.

  • Chrome, Firefox, Microsoft and Apple already block the intermediates. Chrome's removal of emSign ECC Root CA - G3 is due for all devices on October 27 PDT.

  • The gap is outside the browser: on macOS, built-in curl, git, python3 and openssl read /etc/ssl/cert.pem and can still accept the bad chains until Apple ships an update.

  • Apps that ship their own CA bundle need updating too. The tracking site lists fixed versions for Node.js, Python, Go, certifi, Docker, VS Code and more.

UML sequence diagram: an attacker with a recovered weak eMudhra intermediate key presents the same forged TLS certificate to a browser, which rejects it, and to macOS curl or git using /etc/ssl/cert.pem, which accepts it until the roots are removed or macOS is updated

Same forged certificate, two answers: browsers block it, macOS command-line tools may not

What Happened

In a note from eMudhra Leadership dated October 26, the company said a researcher had reported that the private keys for eight of its emSign G3 intermediate TLS CAs were recoverable. "They were right. The flaw was ours. A script error resulted in issuing CA's with weak keys," it wrote, apologising to customers, partners and the wider WebPKI community.

The researcher proved the point the hard way. According to the eMudhra Intermediate CA Compromise disclosure site, they signed the message "We have a problem here - Wayne" with each of the eight private keys and sent it to the root programs on October 17. The site says the keys were generated incorrectly and "anyone can recover them from the certificates," a weakness present since the intermediates were created in April 2025.

India Today reports that the keys were supposed to be random 384-bit numbers, but came out as tiny values such as 4, 56 and 66. It also says India's MeitY has set up a special team to investigate.

In an earlier update on the same page, eMudhra said the keys were made on FIPS 140-2 Level 3 HSMs, and that a key wrap/unwrap step in the ceremony produced a second, weak set of keys, which were the ones published to root stores. It says seven of the eight intermediates never went into production and the one that did never issued a certificate. It has promised a full root-cause analysis via the CCADB process and an independent expert review.

The browsers moved fast. Google's Chrome and Android security teams say Chrome landed a CRLSet block about 100 minutes after the report, and Android got an equivalent update via Google Play services. Google says it's removing the root from the Chrome Root Store, rolling out to all devices on Tuesday morning, October 27 PDT. Sectigo, which had cross-signed the intermediates, says in its advisory that it revoked those cross-certificates on October 19 and ended the cross-signing relationship.

Why It Matters

A CA's intermediate key is a master key for HTTPS. Google puts it bluntly: these keys let "anyone" forge trusted certificates "to impersonate any website" against clients that still trust the CAs.

The good news is that browsers were never the soft target. Google says no certificates from the six TLS intermediates were logged to Certificate Transparency (CT) before the block, so CT-enforcing clients like Chrome couldn't be fooled. eMudhra says it isn't aware of any evidence the weak keys were recovered or exploited before disclosure.

The bad news is that a lot of developer tooling doesn't enforce CT or read revocation lists. The disclosure site warns that "many non-browser clients, including curl" don't enforce CT, which puts them at greater risk. It adds that apps shipping their own CA bundle, including Electron apps such as Slack and Discord, only get the fix when they update.

Apple's support note spells out the Mac problem. Apple has blocked the 12 affected certificates since October 19 and the emSign root since October 23, but tools like curl and git that check /etc/ssl/cert.pem "can still accept these certificates until a future software update." A GitHub report on the disclosure site's repo tested a fully updated Mac on October 21: built-in curl, git, openssl and python3 all accepted a test chain, while Apple's own networking stack refused it.

There's an India angle too. eMudhra's main point of reassurance is that its digital signature and eSign services run on separate infrastructure and weren't affected.

What It Means for Developers

If your code or your CI talks HTTPS outside a browser, check your trust stores this week.

  • Test your tools. The disclosure site offers test hosts. A certificate error from curl https://dv-g3b-emudhra.we-have-a-problem.com/ means that client no longer trusts the bad intermediates.

  • On a Mac, don't wait for Apple if you live in Terminal. Apple documents removing the affected roots from /etc/ssl/cert.pem, but warns it affects every tool using that file and a macOS update may restore it.

  • Point git at a fresh bundle. Another option is an updated Mozilla bundle, for example Homebrew's ca-certificates, set through git's http.sslCAInfo.

  • Update runtimes and bundles. The site lists fixed releases including Node.js 26.12.1/24.22.1/22.23.4, Python 3.15.1/3.14.9/3.13.17, Go 1.27.3/1.26.10, certifi 2026.10.19, pip 26.2.2, Docker Engine 29.9.2 and VS Code 1.143.1.

  • Rebuild containers. Linux images need the patched ca-certificates package from Debian, Ubuntu, Alpine, Fedora or RHEL.

  • Serve a site on emSign ECC Root CA - G3? Google says to get a new certificate from another hierarchy now, before Chrome's removal lands.

UML flow diagram for developers: curl the eMudhra test host, and if it connects, fix macOS cert.pem or git http.sslCAInfo, upgrade runtimes and CA bundles, or rebuild containers with patched ca-certificates, then retest; sites on emSign ECC Root CA - G3 need a new certificate before October 27

Test, fix, retest: closing the eMudhra gap outside the browser

PHP teams got an early taste of this: Composer 2.11 RC1 already rejects the distrusted eMudhra intermediates. For another reminder of how much trust lives in developer tooling, see our report on the OpenCode console breach that exposed AI API keys.

What's Next

The near-term date is Tuesday, October 27 PDT, when Chrome's root removal reaches all devices. Sites still chaining to emSign ECC Root CA - G3 will break in Chrome after that.

Bigger questions remain. Google says it is "closely investigating" whether eMudhra's remaining CA certificates should stay in the Chrome Root Store. eMudhra's full root-cause analysis and independent review are still to come. Apple hasn't said when the macOS update that fixes /etc/ssl/cert.pem will ship, and the disclosure site still lists tools such as certbot and containerd as pending.

FAQ

Were any fake certificates actually used in attacks?

No one has reported any. eMudhra says it isn't aware of any exploitation, and Google says no certificates from the six TLS intermediates appeared in CT logs before Chrome's block.

Is my browser safe?

Yes, if it's up to date. Chrome, Firefox, Microsoft platforms and Apple's Safari and system frameworks already block the compromised intermediates without needing a restart or update for most users.

What's still exposed?

Non-browser clients that don't read revocation data or enforce CT, such as macOS's built-in curl and git, plus apps and libraries that ship old CA bundles. Updating them, or their CA bundle, closes the gap.

Sources

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane.

Learn • Build • Share

Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.