The eMudhra CA Key Compromise: What Companies Should Check and Fix Now

On Saturday 17 October 2026 a security researcher reported that eight intermediate certificate authorities run by eMudhra, an Indian certificate authority, had private keys anyone could work out from the public certificates. Every one of the keys was a number smaller than 256. One of them was the number 4. Six of the eight could issue TLS certificates trusted by Apple, Google, Microsoft and Mozilla; the other two could sign Windows software.

Chrome blocked the six TLS keys an hour and forty minutes after the report, and Firefox the same evening. For people browsing the web, the danger was over by Saturday night.

It was not over for everything else. Servers, containers, Java applications, Python scripts, payment integrations and connected devices check certificates against their own copy of the list of trusted authorities, and most of those copies change only when someone installs an update. Until then, a certificate for any domain signed with one of these keys passes as genuine, and the keys have been public since 20 October.

In the same week GoDaddy started revoking 404,607 certificates because the policy information in them did not match its own published documents. Its customers had to download and install the replacements themselves.

This guide is for the people who have to answer "are we affected?": IT and operations leads, CTOs, and founders whose business runs on a website, an API or a connected product. It covers what happened, taken from the incident records Mozilla, Google, eMudhra, GoDaddy and the software vendors have published; what to check today; what to update this week; and what to put in place so the next incident of this kind is routine. Everything here is as of 22 October 2026, and the incident is still open.

What Happened

eMudhra created the eight intermediates at a key ceremony on 30 April 2025. Its account, posted to Mozilla's incident bug on 19 October: a test of a key wrap and unwrap step, approved as a deviation from its usual procedure, had a flaw that created a second, weak set of keys in the hardware security module next to the intended ones. The labels were similar, the weak keys were used by mistake to create the certificate requests, and eMudhra's root signed them. The same requests went to Sectigo, which cross-signed all eight from its AAA Certificate Services root on 14 May 2025. eMudhra says it has "not yet confirmed the exact root cause".

Mozilla described the result: "P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256." Mozilla received the report at 20:06 UTC and recovered the keys itself at 21:48, "without any knowledge of the method the original reporter used". The researcher says he found them with Google's open source paranoid_crypto library, "out of the box". The weak keys had been part of publicly trusted chains for almost 18 months.

The eight certificates:

Each key sits in two certificates. One was issued by eMudhra's emSign Root TLS CA - G3 or emSign Root CS CA - G3, which chain up to emSign ECC Root CA - G3; the other is Sectigo's cross-certificate from AAA Certificate Services. The second path matters, because some trust stores that never contained an eMudhra root still trust that old Sectigo root.

Was Anyone Attacked?

Nobody has reported misuse, and for browsers there is a good reason to think there was none. Chrome, like other clients that enforce Certificate Transparency (CT), accepts a certificate only if it has been recorded in the public CT logs. Google: no TLS certificates chaining to these six intermediates were logged before its block, so "no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients".

Outside the browser the picture is different. Mozilla's incident page: "many clients outside of the browser ecosystem do not enforce Certificate Transparency. We do not know if attackers exploited the flawed key generation to target these clients." That window opened in spring 2025 and closes for each client only when it is updated. eMudhra says it is not aware of any evidence that the keys were recovered before the disclosure, and Cloudflare says its review found no active exploitation on its services.

Now that the keys are public, forging a certificate takes no skill. Mozilla's incident page lists test servers that present certificates issued with the compromised keys, so that anyone can check their clients against them (the commands are below).

What a forged certificate allows: someone who can intercept the traffic between your software and a service it calls (on a shared network, through a compromised router or a poisoned DNS answer) can impersonate that service, read what your software sends, API keys and personal data included, and change what it receives. Software signed with one of the two code-signing keys would have passed the Windows signature check until Microsoft's block reached the machine.

Who Is Affected

There are three separate problems, and one company can have all of them.

1. Software that still trusts the compromised keys

Almost every company has this one: any program making HTTPS calls whose trust store still contains emSign ECC Root CA - G3 or AAA Certificate Services, and which has not received a block for the eight keys. Typical places:

• Linux servers and container images built before 20 or 21 October. An unpatched Debian 12, for example, trusts both chains.
• Language runtimes that ship their own list: Node.js, Python's certifi, Java's cacerts, PHP's Composer bundle, Rust's webpki-roots.
• macOS command-line tools. Mozilla's incident page says the built-in curl, git, python3, perl, ruby and openssl check certificates against /etc/ssl/cert.pem without checking revocation, and that Apple has not updated that file.
• Windows machines that do not receive Microsoft's automatic updates to its disallowed certificate list, usually because Group Policy switches them off or the network is offline.
• Appliances, devices and third-party software that bundle their own CA file, such as load balancers, VPN gateways, SDKs and embedded controllers.

Each runtime has to be checked on its own. In a test we ran on 22 October, an unpatched Debian 12 machine with Node.js 24.18 accepted the chain that ends at eMudhra's root and rejected the one that ends at Sectigo's, while Python on the same machine accepted both.

2. Companies whose own certificates chain to the removed root

Mozilla and the Linux distributions have removed emSign ECC Root CA - G3, and Chrome follows on 27 October. Valid certificates under that root stop working in each client as it updates. Google's instruction: website operators with such certificates "must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store".

Chrome counted about 30,800 unexpired certificates under the root in CT on 21 October. 30,791 of them came from two intermediates of InCommon, the certificate service Internet2 runs for US universities and research institutions, which issues ECC certificates through CERTInext, eMudhra's platform. 18 came from eMudhra's own intermediates. eMudhra says about 30,000 certificates need migrating, about 97% of them issued through ACME, and that it is issuing replacements from another hierarchy.

If your site is behind Cloudflare in Full (strict) mode and the origin presents a certificate under this root, Cloudflare says the distrust "would cause breakages", and asks customers to "Review your custom origin certificates and server configurations".

RSA certificates from eMudhra's other root, emSign Root CA - G1, are not affected so far. Mozilla says it is not removing that root "at this time"; Chrome is "closely investigating the ongoing inclusion of eMudhra's remaining CA certificates". If you depend on eMudhra or CERTInext certificates of any kind, line up a second certificate authority now.

3. GoDaddy customers

GoDaddy's case has nothing to do with eMudhra, but it hit the same week and many more sites. On 15 October GoDaddy reported to Mozilla that certificates from its GoDaddy and Starfield hierarchies carried certificate policy information (policy OIDs and CPS links) that did not match the profiles in its own CP/CPS, the document in which a certificate authority states what it issues. That is not a security flaw in the certificates. Under the Baseline Requirements, the rules every public certificate authority follows, it is still a reason to revoke them within five days.

404,607 certificates were affected, 396,055 of them domain validated. GoDaddy revoked 170,566 by the deadline of 18 October, 23:45 UTC, and 227,422 by the next morning; its customer notice says the rest were revoked on 21 October. GoDaddy reissues the certificates, but installing them is up to the customer: "visitors to your website may see security warnings, and your site may become inaccessible until a new certificate is installed."

What to Check Today

1. What do your own servers send? For each public hostname, list the issuers in the chain it presents:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

A line naming eMudhra, emSign, one of the EM ... G3B or G3C authorities, or InCommon Intermediate CA - DVG3C, OVG3C or EVG3C means the certificate has to be replaced before 27 October. AAA Certificate Services on its own is normal, since many ordinary Sectigo chains still include it. For mail and directory services add -starttls smtp (or imap, ldap) and the right port. Include internal hosts, load balancers and origins behind a CDN.

2. What has been issued for your domains? CT lists every certificate a public certificate authority has issued for your names, including ones nobody in the company remembers ordering:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

The output also shows which certificate authorities your company actually uses, which is the start of the inventory described further down.

3. Do your clients trust the compromised keys? Mozilla's test servers present certificates issued under the compromised keys, so a certificate error is the good result. Test both families: the first host chains to eMudhra's root, the second to Sectigo's, and a trust store can fail one and pass the other.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl only answers for curl. Run the same request through each application's own TLS stack, in the environment where the application runs:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

The two Python lines are not redundant: urllib uses the operating system's store, requests uses certifi. Repeat each line with the dv-g3b-aaa-emudhra host. For Java, make any HTTPS call to the test servers from the JVM in question, and list whether its store contains either root (Java 9 or later; on Java 8 use -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

A root in a store does not prove exposure on its own, because Go, Node.js, Deno and Rust's rustls-webpki now block the eight keys whatever the store says. The test servers settle it.

4. Windows fleets. Microsoft has published nothing about the incident, but the disallowed certificate list that Windows downloads automatically has blocked all eight keys since 20 October. The exceptions are machines where Group Policy switches off automatic root certificate updates and networks with no route to Windows Update; those need the list delivered another way. certutil -verifyCTL Disallowed shows the copy a machine has cached. Mozilla's incident page offers a script for single machines and says it is "not recommended for enterprise-managed devices".

5. GoDaddy certificates. Check which certificate each server actually presents:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

If the issuer is GoDaddy or Starfield, compare the serial number with the certificates in your GoDaddy account. Where GoDaddy shows "Install your new certificate", the server still has the revoked one.

One rule throughout: do not make an error go away by switching off certificate verification. Cloudflare's words: "It's important to not resolve these errors by disabling verification." A client that does not verify trusts every forged certificate, not only these.

What to Update This Week

There are two kinds of fix. Removing the two roots closes every path for a client that uses that store, but it also breaks the valid certificates under them. Blocking the eight keys by their public key hash, as Go, Node.js, Deno, Electron, rustls-webpki, Composer and Windows do, closes the hole and breaks nothing else. Where your platform offers the second, prefer it.

"Not yet" means nothing had been published by 22 October. Check again before you plan around it.

Four things catch teams out:

• Container images keep the old list. An image built before 20 or 21 October trusts the keys until it is rebuilt on an updated base image, and pulling the same tag helps only once the base image has been rebuilt. Rebuild, redeploy, and ask the vendors whose images you run.
• Processes keep what they loaded. A program reads its trust store when it starts, so restart long-running services after updating. Node.js adds that TLS sessions resumed from before the upgrade are not checked again.
• Applications carry their own CA files. SDKs and applications often ship a cacert.pem or ca-bundle.crt of their own. Search repositories and images for them, for example with find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, and expect more than one: pip, for instance, carries its own copy of certifi.
• Devices wait for their vendor. Ask each vendor in writing which trust store the product uses and when the update ships. Until it does, the device trusts forged certificates for every service it calls, so limit what it can reach.

If you remove AAA Certificate Services by hand, as Debian, Ubuntu ESM, Fedora and Red Hat's workaround do, test connections to services with Sectigo certificates afterwards: some older servers still send a chain that ends at that root.

What to Put in Place Before the Next One

A certificate authority leaving keys this weak is rare. Mass revocations are not. These are the large ones of 2026 recorded in Mozilla's bug tracker:

None of these five was a security failure. In each, a certificate disagreed with the authority's own document, and the Baseline Requirements (section 4.9.1.1) still require revocation within five days. When a key is compromised, or domain validation cannot be relied on, the deadline is 24 hours. Nobody can extend it for you. In DigiCert's 2024 revocation of 83,267 certificates, the Chrome Root Program wrote that it "does not have the authority to grant exceptions"; one customer obtained a court order to stop the revocation of its certificates, and the order was vacated four days later.

How the replacements went says a lot. In July HARICA used ACME Renewal Information (ARI) to tell its customers' ACME clients to renew early, and reissued other certificates itself; in the larger of its two revocations, 87% of the affected names had been replaced when the deadline came. GoDaddy, whose customers download and install each replacement themselves, had revoked 42% of its affected certificates by its deadline.

The renewal cycle is getting shorter in any case:

• Under CA/Browser Forum ballot SC-081, public TLS certificates have been limited to 200 days since 15 March 2026. The limit drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029, when domain validation can be reused for only 10 days.
• Let's Encrypt moves its default to 64-day certificates on 10 February 2027, and to 45 days a year later.
• Public TLS certificates are losing client authentication. Let's Encrypt stopped issuing it on 8 July 2026, and the Chrome Root Program requires certificates issued from 15 March 2027 to be for server authentication only. If you use public certificates as client certificates for mutual TLS, which is common in B2B API integrations, those connections need a private certificate authority.

At 100 days, and then at 47, installing certificates by hand stops being a realistic option. A company that automates for that schedule is also ready for the next mass revocation. What that takes:

1. Know what you have, in both directions. One list of every certificate you serve, with hostname, issuer, expiry, renewal method and owner. A second list of every trust store your software relies on: the operating system package, each language bundle, each CA file inside an application or device. The CT search above starts the first list; a software bill of materials (SBOM) or dependency inventory starts the second.
2. Automate issuance and installation. ACME wherever it can run, with ARI (RFC 9773) so that a certificate authority can tell your clients to renew early. Where a device cannot run ACME, use the vendor's automation, or terminate TLS in front of it on something that can.
3. Keep a second certificate authority ready. A working ACME account with a second authority, tested, and CAA records in DNS that allow both. When one authority is distrusted or revokes in bulk, switching becomes a configuration change.
4. Monitor CT for your domains. Get an alert for every new certificate for your names. You learn about unexpected issuance the day it happens.
5. Treat trust stores as dependencies. Update them through normal patching, and rebuild images on a schedule rather than only when code changes.
6. Write the runbook against the two clocks. 24 hours and five days: who decides, who has access to each system, which systems need manual steps, how to reach each vendor. Rehearse it once a year by swapping the certificate on a service that can afford a mistake. Public certificate authorities have had to keep and test a mass revocation plan of their own since 2025; their customers need the other half.

If You Make Products That Others Run

If your product contains a trust store (a device, an installed application, an SDK), your customers are protected only once your update reaches them. Ship it, and tell customers which versions are fixed. Mozilla's advice to trust store operators: block the eight intermediates if your software can, otherwise "consider whether removing trust in the roots which signed these intermediates is suitable".

The Cyber Resilience Act applies here in two ways. Its reporting obligation, in force since 11 September 2026, covers actively exploited vulnerabilities, and no exploitation has been reported in this case. Its essential requirements, which apply from 11 December 2027, include that vulnerabilities can be addressed through security updates; a product whose trust list cannot be updated would not meet them. Customers covered by NIS2 will ask their suppliers how quickly they handled this, and it helps to have the answer written down.

What Is Still Open

• eMudhra's remaining root. Chrome posted twelve questions to eMudhra on 21 October and has announced no decision on emSign Root CA - G1. Mozilla is not removing it "at this time".
• eMudhra's migration path. It told Mozilla it would move customers to its G1 (RSA) hierarchy; its status page speaks of "an alternate, independently operated, publicly trusted CA hierarchy". Chrome has asked which.
• Microsoft and Apple. Neither has published a statement or removed either root from its store.
• Pending fixes. Red Hat, Amazon Linux, Temurin and Corretto had shipped nothing by 22 October; Bun's fix was merged but not released.
• The root cause. eMudhra has not confirmed it, and has said it will re-verify every key ceremony it has done.
• Sectigo. In a separate case, open since 5 September, Sectigo has declined to revoke certificates whose extended key usage did not match a sentence in its CPS, arguing the sentence was ambiguous. On 18 October it counted about 72 million of them still active. Some participants in the public discussion have called for distrust; no root program has announced a decision. Companies with Sectigo certificates should follow the case.

Where to Get Help

A certificate problem rarely announces itself as one. It shows up as a checkout that stops loading, an integration that stops syncing or a device that stops reporting, usually on a weekend. We help companies get through weeks like this one without an outage, and set things up so the next one is routine:

• An exposure check. We find where your systems make or accept TLS connections, which trust store each one uses and which certificates you serve, including containers, Java services, integrations with banks, payment and logistics providers, and devices.
• The fixes. Updates, rebuilt images, blocked keys or replaced certificates, made through your change process and confirmed against Mozilla's test servers.
• Automation for 2027. ACME with ARI across servers, load balancers and appliances, a second certificate authority, CAA records, CT monitoring and a runbook, ready for 100-day certificates from 15 March 2027.
• The systems nobody wants to touch. Old Java applications, appliances and embedded clients with their own trust stores are what our legacy system and code maintenance service is for.

If you are not sure whether you are affected, write to office@c9group.dev with the domains and platforms you run, or book a call. We will tell you what to check first.