eMudhra CA Key Compromise: What IT Admins Should Do

Eight intermediate certificate authorities run by eMudhra, under its emSign brand, were created with private keys so small that anyone could recover them. One of them was the number 4. With a CA's private key, an attacker who can intercept traffic can mint a certificate for any website, and anything that still trusts that CA will accept it. Browsers moved fast. Many other tools did not, and some will keep trusting the bad CAs even after the operating system is updated.

What happened

• The eight intermediates (six for TLS and two for code signing) used P-384 keys whose private value was below 256, so the keys could be brute-forced almost instantly. The keys were created in April 2025, reported on October 17, 2026, and revoked by eMudhra on October 18.
• Chrome blocked them on October 17 and Android on October 19. Google is removing the parent emSign ECC Root CA - G3 from the Chrome Root Store on October 27.
• Mozilla blocked the intermediates and removed the G3 root from Firefox's trust store on October 20.
• Sectigo had cross-signed copies of these CAs under its widely trusted AAA Certificate Services root; it revoked them.
• There is no public evidence the keys were misused before disclosure. Since then, researchers have logged a large number of test certificates signed with the leaked keys, which shows how easy they are to use.

Who is still exposed

Windows: check the disallowed list is updating

Windows downloads Microsoft's trusted and untrusted certificate lists from Windows Update on its own, roughly daily. On a test machine synced on October 22, the disallowed list blocked all eight compromised intermediates. Microsoft has not published a notice or KB article about the incident, and as of October 22 the parent emSign ECC Root CA - G3 was still trusted by Windows.

Check when a machine last synced the disallowed list:

certutil -verifyctl Disallowed | findstr /i "lastsynctime"

Make sure no Group Policy or registry setting has turned off automatic updates of the disallowed list (EnableDisallowedCertAutoUpdate) or root list (DisableRootAutoUpdate). For machines without internet access, Microsoft documents how to stage the lists on a file share with Certutil -syncWithWU and point clients at it.

To see whether any emSign or eMudhra certificates are installed in the machine stores:

Get-ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\AuthRoot, Cert:\LocalMachine\CA |
  Where-Object { $_.Subject -match 'emSign|eMudhra' -or $_.Issuer -match 'emSign|eMudhra' } |
  Select-Object PSParentPath, Thumbprint, Subject

Seeing an emSign root here is not a sign of compromise by itself. Windows still trusts several emSign roots. What matters is that the eight intermediates are blocked.

Intune: push the bad certificates to Untrusted

The built-in Intune trusted certificate profile only installs to Root or Intermediate stores; it has no Untrusted option. To explicitly distrust a certificate on Windows 10 version 1803 or later (Pro and up), use a Custom (OMA-URI) profile with the RootCATrustedCertificates CSP, which Microsoft describes as the way to "immediately flag certificates that have been compromised":

1. In the Intune admin center, go to Devices > Configuration > Create > New policy, platform Windows 10 and later, profile type Templates > Custom.
2. Add one OMA-URI setting per certificate: ./Device/Vendor/MSFT/RootCATrustedCertificates/UntrustedCertificates/{SHA1 thumbprint}/EncodedCertificate, data type Base64 (file) or string, value set to the certificate's base64 DER encoding on one line.
3. Assign to a pilot group, confirm the certificates appear under Untrusted Certificates in certlm.msc, then assign broadly.

Download the certificates from the CCADB or crt.sh by the SHA-256 fingerprints in the table below, and check the SHA-1 thumbprint of each file before you use it.

The two code-signing CAs matter on Windows: software signed by them would otherwise look legitimate. eMudhra says they issued nothing, but that cannot be checked independently.

Python: why the OS update is not enough

The Python Software Foundation's security team published guidance on October 20. pip always loads its own bundled copy of certifi on top of the system store, and that cannot be switched off. So a pip older than 26.2.2 keeps trusting the bad CAs on a fully patched machine.

python -m pip install --upgrade "pip>=26.2.2" "certifi>=2026.10.19"
uv self update

Run the pip upgrade inside every virtual environment, not only the system Python. Official Docker python images were rebuilt for 3.13, 3.14 and 3.15; the 3.11 and 3.12 images still ship an older pip, so upgrade pip in your Dockerfile and rebuild. Existing containers keep their old trust store until you rebuild and redeploy them.

Everything else that carries its own trust store

• Node.js and Go: both ship or embed CA data in some builds. Install the vendors' current releases and rebuild applications that bundle a runtime.
• Java: update the JDK or JRE, or remove the emSign entries from custom cacerts files.
• Appliances and line-of-business software: firewalls with TLS inspection, proxies, printers and older apps often have their own CA list. Ask vendors whether they have removed the eMudhra CAs.

How to verify

1. certutil -verifyctl Disallowed | findstr /i "lastsynctime" shows a sync date of October 18, 2026 or later on your Windows fleet.
2. python -m pip --version reports 26.2.2 or later in each environment.
3. Container images in use were built after October 20, 2026.
4. If you deployed the Intune profile, the eight certificates appear under Untrusted Certificates on a pilot device.

Frequently asked questions

Do I need to do anything on Windows? Mostly no, if Windows can reach Windows Update and automatic list updates are on. Microsoft's disallowed list blocks the eight intermediates. Microsoft has not published a notice, and the G3 root was still trusted on October 22.

Why does updating the operating system not fix Python? pip always loads its own bundled certifi. Upgrade pip, certifi and uv in every environment and image.

Were the leaked keys used to attack anyone? No public evidence of misuse before disclosure. After disclosure, test certificates signed with the keys appeared quickly, so assume anything still trusting these CAs can be fooled.

Does this affect Microsoft 365? Microsoft has not said so, and Microsoft 365 does not use eMudhra certificates. The risk is on devices and tools that still trust the bad CAs.