eMudhra Certificate Incident: What Happened and What to Do

If you use Chrome, Firefox, Safari or Edge on an updated phone or computer, the main eMudhra certificate incident risk has been blocked in current browsers. Browser and OS vendors blocked the affected certificates between 17 and 20 October, and eMudhra and India’s IT ministry both say its Digital Signature Certificate (DSC) and eSign services are not affected. The people who still have work to do are website owners whose certificates chain to eMudhra’s emSign ECC Root CA – G3, which Chrome is expected to remove on 27 October, and anyone running servers, apps or devices that carry their own list of trusted certificates.

What makes this one remarkable is how basic the mistake was. Mozilla’s engineers found that the private keys behind these certificates were numbers smaller than 256, when they should have been random 384-bit values. Anyone could work them out almost instantly, and anyone holding them could have issued a “valid” HTTPS certificate for any website.

What happened at eMudhra

Bengaluru-based eMudhra is a certificate authority (CA): a company browsers trust to vouch that a website is really who it claims to be. It sells website certificates globally under the emSign brand. On 30 April 2025 it created a batch of 24 intermediate certificates in a key generation ceremony, and eight of them, six for HTTPS and two for code signing, ended up with weak keys.

eMudhra’s explanation in Mozilla’s incident report is that a test of a key wrap/unwrap step created a second, weaker set of keys on the hardware security module, and “these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar)”. In plain terms, the wrong keys were picked because they had similar names, and those were the ones sent to browsers for trust. The company says the hardware itself does not appear to be at fault and that it has not yet confirmed the full root cause.

A researcher named Wayne spotted the flaw on 17 October while scanning the public list of trusted CA certificates, and proved it by signing the message “We have a problem here” with all eight keys. He sent that proof to Apple, Google, Microsoft, Mozilla and eMudhra at 18:05 UTC (11:35 PM IST). Chrome blocked the keys about 100 minutes later through its CRLSet update, and Firefox finished blocking them through OneCRL by 4:29 AM IST on 18 October. Neither needed a browser update or a restart. Apple followed on 19 October and Microsoft on 20 October.

There is also an awkward earlier warning sign. In 2025, revocation lists signed by these same intermediates failed verification, a problem that was reported publicly at the time. eMudhra now says it fixed that by re-signing them “with flawed keys”. The Chrome Root Program says this raises “serious concerns” about eMudhra’s transparency and incident handling.

Why browsers are dropping a whole eMudhra root

Blocking the eight intermediates protects browsers, but plenty of software never checks revocation lists. On 20 October Mozilla said several people had now recovered the keys independently, some publicly, so it removed the root above them, emSign ECC Root CA – G3, from NSS, the trusted certificate list that many Linux distributions and apps reuse. Google is doing the same in the Chrome Root Store, with the change expected to reach all users on Tuesday morning, 27 October, US Pacific time.

That decision has a cost. Every certificate under that root stops working in those clients, including ones that have nothing to do with the leaked keys. Google’s Chrome Root Program counted about 30,800 unexpired certificates in Certificate Transparency logs chaining to it on 21 October, and 99.9% of them came from two InCommon intermediates, which serve US universities and research institutions through Internet2. Only 18 were issued through eMudhra’s own intermediates. That matches eMudhra’s statement that the impact is “contained to a single customer ecosystem in the United States”.

The good news is that no certificates from the leaked intermediates were logged in Certificate Transparency before they were blocked, and Chrome, Safari, Edge and Firefox refuse certificates that are not logged. eMudhra says it has seen no evidence that anyone used the weak keys before the disclosure. CERT-In’s advisory also says the public reports do not establish any confirmed malicious use. The open question is software that does not enforce Certificate Transparency, such as command-line tools, older apps and embedded devices.

Who is affected and what to do

If you rely on eMudhra’s code-signing certificates on Windows, Microsoft has pushed blocks for the two code-signing intermediates through Windows’ automatic certificate trust list updates, so an updated PC will reject software signed through them.

How to check if a website uses the affected eMudhra chain

You can see a site’s certificate chain in a few clicks. In Chrome on a computer:

1. Open the site, then select the site information icon on the left of the address bar.
2. Select Connection is secure, then Certificate is valid.
3. Open the Details tab and look at Certificate Hierarchy.
4. If the top entry is emSign ECC Root CA – G3, or an issuer is named EM DV, OV or EV TLS CA – G3B or G3C, the site is on the affected chain.

In Firefox, select the padlock, then Connection secure, More information and View Certificate, and check the tabs along the top for the same names.

If you manage the server, this command prints the chain your site actually sends. Replace example.com with your domain:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "s:|i:"

If any issuer line (the ones starting with i:) mentions emSign ECC Root CA – G3 or one of the G3B or G3C intermediates, request a replacement certificate from your CA, or switch to another provider, and install it before 27 October. eMudhra says it is moving affected subscribers to an alternative publicly trusted hierarchy. Most of the affected certificates were issued automatically over ACME, so check that your ACME client actually picks up the new chain rather than waiting for its normal renewal date.

How to check if your computer or server still trusts the bad certificates

Mozilla engineer Dennis Jackson runs a public checker at emudhra.we-have-a-problem.com. It serves test pages signed with the compromised intermediates, so a working connection is bad news and an error is what you want. Open the site in your browser and select Run check, or test command-line tools with:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

If curl prints a page instead of a certificate error, that tool still trusts the leaked keys. Updating the trust store usually fixes it. Patched packages are already out for Ubuntu, Debian, Fedora, Arch, Alpine and FreeBSD, and for Python certifi 2026.10.19, Node.js 22.23.4, 24.22.1 and 26.12.1, Go 1.27.3 and 1.26.10, current Java builds, and PHP’s Composer ca-bundle 1.4.16 and 1.6.0, according to the tracker on the same page.

# Debian and Ubuntu
sudo apt update && sudo apt install --only-upgrade ca-certificates

# Fedora, RHEL, Rocky and AlmaLinux
sudo dnf upgrade ca-certificates

# Python projects that bundle certifi
pip install --upgrade certifi

Mac users have one gap. macOS itself blocks the intermediates, so Safari and normal apps are fine, but the built-in Terminal tools such as curl, git, python3 and openssl read an older certificate file that does not check revocation. Apple had not updated that file when the checker page was last updated. The checker page has a workaround for developers, and a full Time Machine backup before updating macOS is sensible whenever Apple ships its fix.

Smart home gear and older routers are the hardest part, because many only update their trusted certificates through firmware updates that rarely arrive. If yours has not had an update in years, that is one more reason to plan a replacement; our Wi-Fi 7 router guide covers what is worth buying now.

What it means for eMudhra DSC and eSign users in India

For Indian DSC and eSign users, the distinction is important. The USB token you use for GST returns, MCA filings or income tax, and Aadhaar-based eSign, come from eMudhra’s Indian business under the Controller of Certifying Authorities (CCA). eMudhra says that business runs on separate infrastructure, and CERT-In says those services are not impacted by this incident.

CERT-In published advisory CIAD-2026-0050 on 21 October. Its advice for ordinary users is simple: install browser and operating system updates, and never click through a certificate warning or turn off certificate checks. A fake site that looks perfect is exactly what a stolen CA key enables, which is why the same habits that protect you from scam links in Google Messages matter here too.

My take

The browser response worked the way it should. Four companies blocked the keys within three days, users received protections between 17 and 20 October, and most browser users did not have to act by hand. The weak point is eMudhra’s process: wrong keys picked because of similar labels, two audit cycles that did not catch it, and an earlier signing error that was patched over instead of investigated.

That matters for India beyond this one root. eMudhra is the only Indian CA trusted by the major browsers, and Google says it is now “closely investigating” whether eMudhra’s remaining certificates should stay in the Chrome Root Store. If your business uses emSign website certificates, I would line up a second certificate provider now, even if your current chain is fine today.

FAQ

Is my DSC token safe after the eMudhra incident?

Yes. eMudhra and CERT-In both say the Indian DSC and eSign services are unaffected. The leaked keys belonged to eMudhra’s global website certificate business, which uses separate systems.

Do I need to update my browser?

Chrome and Firefox applied the block automatically without an update or restart. Keeping automatic updates on is still the best protection, and Firefox 158.0.1 or later bakes the block in for people who have disabled background updates.

Were any websites actually impersonated?

There is no public evidence of that. No certificates from the leaked intermediates were logged before they were blocked, which protects browsers that enforce Certificate Transparency. Software that skips those checks is the remaining unknown.

What happens on 27 October?

Chrome expects to stop trusting emSign ECC Root CA – G3 for all users on 27 October. If Chrome removes that root as planned, websites still using certificates under it will show a security error until they install a new certificate.

• SourceGoogle: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates

• SourceMozilla Security Blog: Protecting Firefox users after the eMudhra compromise

• SourceMozilla Bugzilla 2083449: eMudhra private key compromise of intermediate certificates

• SourceeMudhra: Statement on recent certificate security incident

• SourceeMudhra: Statement on distrust of Global TLS intermediate and root CA

• SourceeMudhra Intermediate CA Compromise checker and patch tracker

• SourceCERT-In: eMudhra certificate incident advisory