The eMudhra certificate incident explained: could your website's HTTPS connection be affected?

In the middle of October 2026 the web’s trust system had one of its rare visible failures. Eight intermediate certificate authorities run by eMudhra, an Indian company that sold publicly trusted TLS certificates under the emSign brand, turned out to have private keys that anyone could work out from the public half. Within hours of the report, Chrome and Firefox had blocked them. Within a day, eMudhra had revoked all eight. Within ten days, every major browser and operating system had removed the root certificate above them, and eMudhra had announced it was leaving the public TLS business.

For most website owners the practical effect is nothing, because the eight intermediates never issued a certificate to any website. But “most” is not “all”, and the incident is a clean example of how the chain of trust behind the padlock works, where it can break, and how to check your own site in two minutes. This article covers what happened, who was affected, what the browser vendors did, and a step-by-step walkthrough of checking a certificate chain.

What happened

The weak keys

Every certificate authority has a private key it uses to sign the certificates below it. A properly generated elliptic-curve P-384 private key is a random number with about 384 bits of entropy; guessing it is not a realistic attack. The eight eMudhra intermediates did not have that. Mozilla’s incident record is blunt: all eight keys used integers less than 256. Anyone with the public certificate could try every value from one upwards and have the private key in a fraction of a second. Mozilla’s own engineers recovered the keys independently on the evening of 17 October, less than two hours after receiving the report, without knowing how the researcher had done it.

How it happened

The keys were created at a key-generation ceremony on 30 April 2025 that produced 24 intermediates. eMudhra’s account is that a deviation from the normal procedure was approved to test a key wrap-and-unwrap operation, a flaw in that code produced a second set of keys that were weak, and because the key labels were similar, the weak keys were the ones used to make the certificate signing requests. Those requests were signed by eMudhra’s own root and sent to Sectigo for cross-signing. The hardware security modules were FIPS 140-2 Level 3 certified; the failure was in the steps around them. The weak keys went unnoticed for about 18 months and through two audit cycles. In its first statement eMudhra called it “a script error” and said: “The flaw was ours.” On 30 October it appointed KPMG as an independent reviewer.

The eight certificates

Six were TLS issuing CAs under emSign Root TLS CA - G3 (the DV, OV and EV TLS CAs, G3B and G3C variants). Two were code-signing CAs. eMudhra says seven of the eight were never used in production and the one that was in production issued no certificates, which it says Certificate Transparency records confirm. Google’s Chrome Root Program likewise found no certificates from the six TLS intermediates in CT logs before it blocked them.

The timeline

Date	What happened
30 April 2025	Key ceremony creates 24 intermediates; eight receive weak keys
17 October 2026, 18:05 UTC	Chrome Root Program receives the researcher’s report; blocks the six TLS intermediates by 19:45 UTC
17 October, 20:06 UTC	Mozilla receives the report; recovers the keys itself at 21:48; Firefox block live via OneCRL at 22:59
18 October, 09:24 to 09:38 UTC	eMudhra revokes all eight, reason caCompromise; Sectigo revokes its cross-signed copies
20 October	Firefox 158.0.1 and ESR releases carry the block to users whose settings had prevented the earlier update; Mozilla announces emergency removal of emSign ECC Root CA - G3
22 October	Apple adds its protections; eMudhra announces it will leave the public TLS business
26 October	Microsoft releases out-of-band Windows updates (KB5134133 for Windows 11, KB5134125 for Windows 10) removing seven certificates from the trust list, for machines that do not receive automatic trust-list updates
27 October	Chrome’s removal of emSign ECC Root CA - G3 reaches all devices; Edge removes the same seven certificates
28 October	WordPress 7.1.4 ships with updated bundled root certificates
30 October	eMudhra appoints KPMG as independent reviewer

Who is actually affected

Websites

The certificates under the affected G3 hierarchy number about 30,800, and eMudhra says they belong to a single customer ecosystem in the United States, which is being moved to an alternative issuance path and then to other providers. About 97% of them can be renewed automatically through ACME. Other eMudhra TLS customers were moved to alternative providers at no cost, with Sectigo-issued certificates offered as one option. If your certificate did not come from eMudhra or emSign, your website is not involved.

What the incident did not touch

eMudhra is better known in India for digital signature certificates (DSCs) and eSign, used for company filings, tax returns and document signing. Those services, together with emSigner, CertiNext, emCA, PrivaTrust and SecurePass, run on separate infrastructure according to the company, and they are not part of this incident. The incident concerns the global, publicly trusted TLS business only.

Everyone else, indirectly

Even sites with no eMudhra connection were touched in one way: their visitors’ browsers and operating systems updated their trust stores, and software that bundles its own root certificates, such as WordPress, Python’s certifi package and many Linux distributions, shipped updates. That is routine, and it is the part of the system that worked.

Why removing the root was the right call

If no bad certificates were issued, why distrust the whole root rather than just the eight intermediates? Because what a root programme trusts is not a certificate but a CA’s ability to handle keys. The same ceremony that produced the weak keys produced the good ones. Two audits had not noticed. A separate Mozilla bug records certificate revocation lists for a related eMudhra hierarchy signed with the wrong key. Once key-handling has demonstrably failed, nothing under the root can be relied on with confidence, and the only response that does not depend on eMudhra’s word is to stop trusting the root and give its customers time to move. It is also why a quiet misuse between April 2025 and October 2026 against a client that never checked Certificate Transparency can never be ruled out, only judged unlikely.

A note on the demonstration certificates: after the revocation, researchers used the recovered keys to sign and log large numbers of proof-of-concept certificates to CT, which is why some write-ups mention six-figure counts of certificates “issued” by the compromised CAs. Those were demonstrations against already-distrusted intermediates, not attacks on real sites.

How to check your own site’s certificate chain

This takes two minutes and is worth doing for every domain you run, not only because of eMudhra. The chain is the list of certificates between your site’s own certificate and a root the browser trusts; each link has to be valid or the padlock fails.

In the browser

1. Open your site in Chrome or Firefox and click the padlock, then the connection or certificate details.
2. Open the certificate viewer and look at the hierarchy. You will see three or four entries: your site’s certificate at the bottom, one or two intermediates, and the root at the top.
3. Read the issuer organisation on each. For this incident you are looking for emSign or eMudhra in any entry. Most sites will show Let’s Encrypt, DigiCert, Sectigo, GlobalSign, GoDaddy, Amazon, Google Trust Services or Cloudflare.

From a terminal

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"

The output lists each certificate in the chain your server sent, with s: for subject and i: for issuer. Read the issuer lines. If your server sends the intermediates correctly, the last issuer line names a root. If any line mentions emSign or eMudhra, you are involved and should re-issue elsewhere.

To check the root your server chains to without the noise:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Online

Enter your domain at crt.sh to see every certificate ever logged for it and which CA issued each; this also catches certificates you did not know existed. SSL Labs shows the full chain as browsers see it and flags a missing intermediate. BCDRPulse’s TLS scan does the same check against a domain you have verified as yours and keeps a dated report, so you can show what your chain looked like on a given day.

If you find emSign in your chain

Re-issue from another publicly trusted CA now. Do not wait for the certificate to fail, because the failure arrives on your visitors’ machines as their browsers update, and you will hear about it from them. eMudhra’s partners are issuing replacements at no cost; if your certificate is managed through ACME, pointing the client at a different CA is usually a one-line change.

The clients that did not update themselves

Browsers handled this incident in hours. The machines that did not are the ones with their own certificate bundles and no automatic trust updates:

• Servers that call other services over HTTPS. PHP, Python, Node, Java and Go each carry or reference a CA bundle. Linux distributions update ca-certificates through their package managers; run your updates. WordPress 7.1.4 updated the bundle PHP uses for outbound calls from WordPress itself.
• Scripts and tools that skip revocation. BleepingComputer notes that macOS’s built-in curl may keep trusting the compromised certificates because its bundle does not check revocation. A tool that neither checks revocation nor receives a trust-store update will trust a revoked certificate indefinitely.
• Appliances, proxies, load balancers and devices with trust stores that only change on firmware updates.
• Disconnected Windows machines. Microsoft’s out-of-band updates exist for systems that cannot reach its automatic certificate trust list service; install them on anything air-gapped.

Keyfactor’s advice for organisations is the right shape: inventory every certificate and every trust store, not only the ones on web servers; search for anything chaining to the affected root or intermediates; and update trust stores everywhere, not just in browsers.

What this incident teaches about running a website

Certificate agility is a resilience control. A CA can lose trust overnight, as this one did. If replacing your certificate means a ticket, a purchase and a manual install, you have a single point of failure you did not know about. Automate issuance through ACME, keep an account with a second CA, and know how long a replacement takes. The same preparation covers the next change in the system, such as the industry’s move to shorter certificate lifetimes, which our TLS configuration check covers.

Watch your chain, not only your expiry date. Most monitoring checks whether a certificate is about to expire. Fewer check whether the chain is complete and whether the root is still trusted. A certificate can be valid and still fail because a browser stopped trusting its root.

Know what you depend on. A certificate inventory is the TLS equivalent of a backup inventory: tedious until the day you need it in a hurry. If you had to answer “which of our systems chain to emSign?” today, could you?

How BCDRPulse can help

BCDRPulse’s TLS scan (Pro) reads your site’s certificate chain from the outside, checks the protocols, ciphers and certificate details against current practice, and records the result in a dated report. Uptime monitoring on the Free plan tells you within minutes if your site stops answering, which is what an untrusted chain looks like to a visitor. Every check runs only against a domain you have verified as yours. See pricing for the plans.

The bottom line

Eight certificate authorities had private keys you could guess by counting to 256. No website certificate was forged by them, the browsers blocked them within hours, the root above them is gone from every major trust store, and the company that ran them is leaving the business. Check your own chain anyway: one padlock click or one openssl command, looking for emSign or eMudhra. Then update the trust bundles on the machines that do not update themselves, and make sure you could swap your certificate to another CA in an afternoon if your own issuer were next.