The eMudhra Certificate Compromise: Why Your SSL Chain Matters

October 30, 2026 · 4 min read

The padlock in your browser’s address bar rests on a chain of trust: your site’s certificate is signed by an intermediate authority, which is signed by a root that browsers and operating systems trust. In October 2026 that chain broke for one authority. Eight private keys belonging to intermediates of eMudhra, a large Indian certificate authority, were found to be recoverable: six used for TLS (the certificates behind HTTPS) and two for code signing. With those keys, someone could mint a certificate for any domain, yours included, and browsers would accept it as genuine.

If your site uses a Let’s Encrypt, Sectigo, DigiCert or GlobalSign certificate, which covers almost every site we build, you can stop worrying about your own padlock after the next paragraph. The incident still matters for how your browsers, servers and payment integrations handle trust, so it is worth five minutes.

What the vendors did

• 20 October: Microsoft added the affected CAs to the Windows Disallowed Certificate Trust List.
• 22 October: Edge 156 shipped an emergency CRLSet update blocking TLS certificates signed by the compromised intermediates, delivered through the component updater so no browser upgrade was needed. WebView2 (the engine inside many Windows desktop apps) got the same block.
• 26 October: An out-of-band Windows update removed seven certificates from the Windows trust store: six eMudhra G3 roots and a cross-sign from AAA Certificate Services.
• 27 October: The same seven were removed from Edge’s own trust list. Microsoft says it is evaluating the remaining eMudhra roots separately.

Microsoft was careful to say this was a problem in eMudhra’s hierarchy, not a compromise of Microsoft’s systems, and eMudhra has revoked the affected intermediates. Other browser makers run their own root programmes and are making their own decisions; the practical effect is the same: certificates chaining to those roots are becoming untrusted, device by device, as updates land.

Why it matters even if you never heard of eMudhra

Impersonation. A certificate forged with a stolen TLS key passes as valid for any hostname. Combined with DNS or Wi-Fi tampering, an attacker could sit between a visitor and your site and read or change the traffic, with the padlock still showing. Browser blocks close that door on updated devices; they do nothing for devices that are not updated.

Software that does not check revocation. Microsoft’s advisory makes a point we repeat to clients often: many libraries, mobile apps and server-side integrations never consult revocation lists or the disallowed-certificate list. A payment webhook, a mobile app talking to your WooCommerce REST API, or an old PHP cURL build may keep trusting a revoked chain indefinitely. The browser is the easy part; your own integrations are where the risk lingers.

Supply chain. Two of the eight keys were for code signing. Software signed with them would look legitimate to Windows. If you run Windows machines in the business, this is a reason to keep Windows Update on and to be suspicious of any installer that arrives by email this month.

What MymenTech clients should do

1. Check your own chain (2 minutes). Open SSL Labs, enter your domain and read the “Certification Paths” section. If any issuer in the chain mentions eMudhra, emSign or AAA Certificate Services, you need a new certificate from a different authority before the trust-list changes reach your visitors. Sites we host use Let’s Encrypt and renew automatically; none chain to the removed roots. We re-checked every client domain on 27 October.
2. Update browsers and Windows. The blocks only protect patched devices. Edge updates itself; Windows needs the 26 October out-of-band update, which arrives through Windows Update.
3. List what talks to your site over HTTPS. Payment gateways, SMS and email APIs, mobile apps, ERP connectors. For each, confirm the client library validates certificates and checks revocation, or at minimum runs a current TLS stack. If a vendor cannot answer, that is an answer.
4. Keep certificate automation on. Hand-renewed certificates are the ones that chain to odd authorities, expire on weekends and get replaced in a hurry. Let’s Encrypt plus auto-renewal is free and has none of these problems.
5. Do not re-trust removed roots “for compatibility”. Microsoft explicitly warns against it. If an internal tool breaks, fix the tool.

The bigger lesson

Certificate authorities are infrastructure, and infrastructure fails. The web has been shortening certificate lifetimes (47-day certificates are coming in 2029) precisely so that incidents like this expire out of existence quickly. The sites that cope best are the ones where renewal, revocation checking and browser updates are boring and automatic. If any of those are a manual task in your business today, that is worth a conversation.

Sources: Microsoft Security Response Center, October 2026; Microsoft Edge 156 release notes.