Skip to main content
Change Risk Intel
Cybersecurity

eMudhra Certificate Compromise: A Trust Store Change Runbook

Ben Ennis Founder, Ennis Studio · Editor, Change Risk Intel · 13 min read

No affiliate links appear in this article. Facts come from the root programs, eMudhra, and the maintainers of each trust store, linked inline and in Sources. This is a defender’s runbook. It doesn’t cover how the keys were recovered.

Table of contents

Why this matters

Most certificate incidents are a browser problem, and browsers solved this one fast. Google’s Chrome Root Program blocked the affected keys at 19:45 UTC on October 17, under two hours after the report. Mozilla had its OneCRL update out to standard Firefox installs by 22:59 UTC the same day.

The servers, build agents and containers that call your APIs, payment processors and SaaS vendors don’t use OneCRL or CRLSets. They trust whatever CA bundle sits in the operating system image, the language runtime or the application itself. The eMudhra disclosure site says many clients “do not consume revocation information” and need software updates. It names apps with their own CA bundles and Electron apps such as Slack and Discord.

That makes this a change management problem. You need an inventory of trust stores, a set of package and image updates, at least one certificate replacement deadline (October 27), and evidence that each fix actually took. Cloudflare described the same pattern in its own response. It updated shared trust stores and base images, then “paired these updates with reloads, restarts, and image deployments needed to activate them.”

What happened to the eMudhra intermediates?

eMudhra’s incident statement says eight intermediate CAs in its global TLS business were created in a key generation ceremony on April 30, 2025. A wrap and unwrap step “produced a second, weak set of keys alongside the original strong keys,” and the weak ones were the keys published to browser root stores. The flaw went unnoticed until a researcher reported it on October 17, 2026. eMudhra revoked all eight the next day. It says none of them had issued a certificate and seven were never used in production.

Apple’s support note gives the clearest map of the chains. Six of the eight intermediates issue TLS certificates, and two issue code-signing certificates. Each TLS intermediate exists as two certificates, for 12 in total. One is issued by emSign Root TLS CA - G3, which chains to emSign ECC Root CA - G3. The other is cross-signed by Sectigo and chains to AAA Certificate Services. Apple says eMudhra and Sectigo revoked the affected certificates.

The risk for clients is impersonation, not broken encryption. Google says the weak entropy “enabled anyone to forge trusted HTTPS certificates to impersonate any website” against clients that still trusted these CAs. Google also found no TLS certificates chaining to the six TLS intermediates in Certificate Transparency logs before the block. So CT-enforcing clients such as Chrome couldn’t have been attacked with them. Most non-browser clients don’t enforce CT. The disclosure site says it isn’t known whether anyone used the keys against clients outside the browser ecosystem.

On October 22, eMudhra announced it would exit the global TLS certificate business. It says TLS is about 1% of revenue and it will replace affected customers’ certificates free of charge through partners. It gave no exit date.

Which trust stores have been fixed, and when?

We pulled the date each major trust store shipped a fix from its maintainer’s own notice. Day 0 is October 17, when the report reached the root programs.

Horizontal bar chart of eMudhra remediation dates by trust store: Chrome CRLSet and Firefox OneCRL on day 0, eMudhra revocation on day 1, rustls webpki-roots, Apple intermediate block and Android on day 2, NSS 3.131.1 and Ubuntu ca-certificates on day 3, Node.js on day 4, Apple root block and Fedora on day 6, and Chrome Root Store root removal on day 10, October 27

Trust storeWhat shippedDateSource
Chrome (CRLSet)SPKI block of affected intermediatesOct 17Google
Firefox (OneCRL)Intermediates blocked, no restart neededOct 17Mozilla
Apple platforms12 TLS intermediate certificates blockedOct 19Apple
Android, GooglebooksEquivalent block via Google Play ServicesOct 19Google
Rust (webpki-roots)1.0.10 removes emSign ECC Root CA - G3Oct 19rustls PR 133
Python (certifi)emSign roots removed, unaffected ones restoredOct 19certifi issue 439
Microsoft platformsIntermediates blockedOct 20Disclosure site
NSS 3.131.1, Firefox 158.0.1, ESR 115.43.1 and 153.5.1Root removed from NSSOct 20Mozilla
Ubuntu ca-certificatesTwo cross-signing roots removedOct 20Ubuntu
Node.js 22.23.4, 24.22.1, 26.12.1Bundled CA update for the eMudhra compromiseOct 21Node.js
Apple platformsemSign ECC Root CA - G3 blockedOct 23Apple
Fedora ca-certificates (-2 build)Pushed to Fedora 45 stableOct 23Fedora Bugzilla
Chrome Root StoreemSign ECC Root CA - G3 removedOct 27Google

Browser revocation channels moved in hours. Library and OS bundles took two to six days, and Fedora’s needed a second build. A commenter on the Fedora bug found the first update still trusted emSign Root CS CA - G3, which issued the two code-signing intermediates. The last item on the list is a root removal, not a revocation, and it lands on October 27.

Where are you still exposed?

A host is only protected once three things are true. The package is updated, the process has reloaded the bundle, and nothing in the app overrides the system store. Check these places in this order.

Operating system images. Ubuntu’s fixed versions start at 20260816ubuntu0.22.04.1 on 22.04 and 20260816ubuntu0.24.04.1 on 24.04. Ubuntu notes that 20.04 and older need Ubuntu Pro (ESM) to get the fix. Base images you built before October 20 still carry the old bundle until you rebuild them.

Language runtimes with their own bundles. Node.js ships its own root list, so updating the OS doesn’t fix a Node process that uses the bundled store. You need 22.23.4, 24.22.1 or 26.12.1. Python code using certifi needs a version from October 19 or later. Rust services that compile in webpki-roots need 1.0.10 and a rebuild, because the roots are baked into the binary.

Java. Ubuntu says its OpenJDK uses the system store, but Java’s cacerts doesn’t sync correctly. Admins need to delete /etc/ssl/certs/java/cacerts and run update-ca-certificates --fresh. Ubuntu adds that Oracle issued CVE-2026-91403 for Oracle Java users.

macOS command-line tools. Apple’s block covers its frameworks. Tools that read /etc/ssl/cert.pem will be fixed “in a future macOS update,” with no date given.

Electron apps, appliances and vendor software. These carry their own bundles and update on their vendor’s schedule. The disclosure site says Electron apps are fixed only after they ship a build on a patched Electron release.

Inbound trust you configured. Cloudflare told customers to review mutual TLS trust stores and uploaded CAs used to verify client certificates. It also said to check custom origin certificates if they use Full (strict) mode.

Can the fix break things?

Yes, in two ways, and both belong in the change record.

First, Chrome’s root removal will break legitimate sites. Google says some certificates chaining to emSign ECC Root CA - G3 “will cease to function in Chrome.” Operators with those certificates “must immediately acquire and install a new TLS certificate from another PKI hierarchy.” eMudhra puts the affected certificates in “a single customer ecosystem in the United States.” If you buy from eMudhra or one of its partners, check every certificate chain this week rather than assuming you aren’t that customer.

Second, some distributions removed more than the eMudhra roots. Ubuntu removed both emSign Root TLS CA - G3 and Comodo AAA Certificate Services, because both cross-signed the compromised intermediates. On the Fedora bug, the ca-certificates maintainer said Fedora would also remove AAA Certificate Services, since there was not yet a way to distrust only the intermediates across all crypto libraries. The disclosure site warns that removing AAA Certificate Services may affect unaffected websites that chain to it. Any partner, API or internal service whose chain still ends at that legacy Sectigo root could start failing when the updated bundle lands. Ubuntu says AAA Certificate Services was already gone from its bundles on 22.04 and newer, so the new exposure sits mostly on older releases and on other distributions. Test before you push to production.

How should change control handle it?

We’d treat this as one emergency change with child tasks, not dozens of separate tickets. The risk is the same across every host: clients that still trust a forgeable CA. The fix is also the same everywhere: update the bundle, reload or rebuild, then verify. Our BOD 26-04 decision matrix uses the same split between an urgent parent change and tracked child work.

A few rules make this manageable:

  • Separate the deadlines. Trust store updates are open-ended, so do internet-facing clients first. Certificate replacement has a hard date of October 27 in Chrome. Run them as two tracks so the bundle work doesn’t hold up the replacement.
  • Count a rebuild as part of the change. For containers and compiled binaries, a patched package in the repository changes nothing until the image or binary is rebuilt and redeployed. Close child tasks on deployment evidence, not merge evidence.
  • Pre-approve the pattern. Cloudflare’s sequence of trust store update, reload, image redeploy and separate review of bundled apps is generic. Write it up once as a standard change for CA distrust events. The next one won’t need a full emergency CAB. Our CAB agenda generator can produce the review item.
  • Log what you removed. Record which roots each update dropped, especially AAA Certificate Services. Then whoever handles a TLS failure next month can link it to this change.

For more change-ready security analysis, see the cybersecurity hub and our guide to reading a CISA KEV entry.

What to do about it

  1. List every trust store you run. Include OS packages, base images, Node, Python, Java, Rust and Go builds, Electron apps, appliances, and any mTLS or client-certificate trust lists.
  2. Update the OS bundle. Install the fixed ca-certificates and libnss3 packages. Ubuntu’s single-component command is sudo apt install --only-upgrade ca-certificates 'libnss3*'. Then confirm with dpkg -l ca-certificates 'libnss3*'.
  3. Update runtime bundles. Move to Node.js 22.23.4, 24.22.1 or 26.12.1, a certifi release from October 19 or later, and webpki-roots 1.0.10. Regenerate Java cacerts.
  4. Rebuild and redeploy. Rebuild container images and statically linked binaries, then restart the long-running processes that cache trust stores.
  5. Find certificates chaining to emSign ECC Root CA - G3. Inspect the chains on your public endpoints and replace any that end at that root before October 27.
  6. Test for collateral breakage. Before rollout, check partner and API endpoints against a bundle without AAA Certificate Services.
  7. Verify with a test host. The disclosure site runs checker hosts. A client that connects successfully still trusts the compromised intermediates; a certificate error means it’s fixed. Note that network failures can also produce errors.
  8. Close on evidence. Attach package versions, image digests and checker results to each child task.

FAQ

What is the eMudhra certificate compromise?

eMudhra, an Indian certificate authority, created eight intermediate CAs in April 2025 with weak private keys. A researcher reported it on October 17, 2026. Anyone who recovered a key could forge certificates for any website that clients trusting those CAs would accept. eMudhra revoked all eight on October 18.

Were any fraudulent certificates used?

Google found no TLS certificates chaining to the six TLS intermediates in Certificate Transparency logs before the block. So CT-enforcing browsers such as Chrome couldn’t have been attacked with them. Whether anyone targeted non-browser clients, which usually don’t enforce CT, isn’t known.

Is updating my browser enough?

For browsing, mostly yes. Chrome and Firefox pushed blocks without a restart on October 17. Servers, containers, language runtimes, Electron apps and appliances use separate trust stores and need their own updates.

What happens on October 27?

Chrome removes emSign ECC Root CA - G3 from the Chrome Root Store, effective Tuesday morning Pacific time. Legitimate certificates chaining to that root stop working in Chrome, so their operators need replacement certificates from another CA hierarchy.

Why did Ubuntu remove AAA Certificate Services?

Sectigo had cross-signed the compromised TLS intermediates under that root. Ubuntu removed both cross-signing roots so the intermediates would no longer be trusted. The trade-off is that unaffected endpoints chaining to AAA Certificate Services may also fail.

Is this an emergency change?

In most change policies, yes. The exposure is active, the fix is well defined, and Chrome’s root removal has a fixed date. Run it as one emergency parent change with child tasks per platform, and close each task with evidence of deployment.

How do I check whether a client is still vulnerable?

Point it at one of the checker hosts on the eMudhra disclosure site. A successful connection means the client still trusts the compromised intermediates, and a certificate error means it doesn’t. Confirm installed package versions as well, because a network failure can look like a pass.

Sources

#emudhra #certificate authority #trust store #tls #pki #emergency change #ca-certificates

Published October 26, 2026.