eMudhra Intermediate CA Compromise: What It Means and What to Do

What happened in the eMudhra intermediate CA compromise?

Eight intermediate CA certificates that eMudhra created in April 2025 were generated with private keys so small that anyone can work them out from the certificate. A researcher reported this to the root programs on October 17, 2026, proving it by signing the message "We have a problem here - Wayne" with each of the eight keys. Mozilla says the keys "could allow attackers to issue fraudulent HTTPS certificates for websites they do not control".

Six intermediates were for website (TLS) certificates and two for code signing. Each also existed as a second certificate with the same key, cross-signed by Sectigo's AAA Certificate Services root.

eMudhra has said the incident does not affect its root CA private keys or its other intermediates, that only one of the eight was in production, and that none issued an end-entity certificate. As reported, its preliminary explanation is a flaw in the script used at the key-generation ceremony, which produced a second, weaker set of keys; it says its RSA intermediates were generated another way and are not affected.

How weak were the eMudhra keys?

The eMudhra keys were weak enough to find by counting. A P-384 private key should be a random 384-bit number. These were between 4 and 237, so a program that multiplies the curve's base point by 1, 2, 3 and so on, and compares each result with the public key in the certificate, finds every one of them almost immediately.

We ran exactly that on October 21, 2026, in Python 3.13 with the cryptography library 50.0.1, against the eight certificates from the disclosure site's proof bundle. All eight keys came out in 0.1 seconds, and they match the values other researchers reported. We also checked the reporter's proof with OpenSSL 3.0.13: all eight signatures over the "We have a problem here" message verify against the public keys in the certificates.

EM-OV-TLS-CA-G3C 4
EM-EV-TLS-CA-G3C 56
EM-OV-CS-CA-G3B 66
EM-EV-TLS-CA-G3B 115
EM-OV-TLS-CA-G3B 155
EM-DV-TLS-CA-G3B 156
EM-DV-TLS-CA-G3C 230
EM-OV-CS-CA-G3C 237
searched up to 237 in 0.1s

Who has to do something about the eMudhra compromise?

Two groups have to act: people who run software that makes HTTPS connections outside a browser, and eMudhra customers whose certificates chain to emSign ECC Root CA - G3. Everyone else, including website owners who use other CAs, has nothing to change.

Disclosure: My-SSL sells Certum certificates, including the SSL certificates linked on this page.

Were browser users ever exposed?

Browser users were well protected. Chrome, Firefox, Safari and Edge require certificates to appear in Certificate Transparency logs, and according to the Chrome Root Program, as reported by The Hacker News, no certificate chaining to the six TLS intermediates had been logged before Chrome blocked them. The disclosure site concludes that these CT-enforcing browsers "could not have been attacked". The browsers then blocked the intermediates directly.

Chrome pushed a block through its CRLSet at 19:45 UTC on October 17, matching the intermediates by public key so that the Sectigo cross-signed copies were covered too. Mozilla received the report at 20:06 UTC and had a OneCRL block out to standard Firefox installations by 22:59 UTC. Apple followed on October 19 and Microsoft on October 20. On the revocation side, we read the CAs' own revocation lists: eMudhra revoked all eight intermediates between 09:24 and 09:38 UTC on October 18 with the reason "CA Compromise", and Sectigo revoked all eight cross-signs at 10:35 UTC on October 19.

I have an eMudhra certificate. What should I do?

If your certificate chains to emSign ECC Root CA - G3, replace it now. Your own key is not compromised, but Mozilla's NSS 3.131.1 has dropped that root, so clients whose trust bundles are built from Mozilla's list (certifi 2026.10.19, for example) reject it once they update, and Chrome is removing it in Chrome Root Store version 43, expected to reach devices around October 27, 2026, according to reports. eMudhra gave Mozilla an initial estimate of about 30,000 certificates to migrate, and it has stopped issuing from the intermediates under that root.

Check the chain your server sends. If any line names emSign ECC Root CA - G3 or emSign Root TLS CA - G3, the certificate is in scope:

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

Mozilla warned that removing the root "will impact the availability of some servers" until they move to new chains, so the order matters: get the replacement, install it with its full chain, check it, and only then let the old one go. If you have a CAA record, add the new CA first or the order will be refused; our guide to switching certificate authority without downtime walks through the overlap. For a Certum replacement, the SSL certificate comparison shows the DV, OV and EV choices. If you stay with eMudhra, ask which root the replacement chains to.

I run software outside a browser. What do I update?

Update every trust store and runtime your services use, then rebuild and restart. Many non-browser HTTPS clients do not check revocation, so they keep trusting a chain until their root bundle or code changes. That leaves a window in which anyone holding one of the keys could impersonate any site to that client.

We saw this directly. The disclosure site publishes chains from test hosts whose certificates are signed with the compromised keys; the one we checked is dated October 20 and chains to EM DV TLS CA - G3B, which eMudhra had revoked two days earlier, so only someone holding that key could have signed it. With OpenSSL 3.0.13, which does not check revocation by default, the chain verified as OK against the trust bundle from Python's certifi 2026.7.22 and failed against certifi 2026.10.19, which removed emSign ECC Root CA - G3.

Two warnings from Cloudflare's write-up are worth repeating. Do not make the resulting errors go away by switching off verification: it is "important to not resolve these errors by disabling verification". And test the path your application actually uses, because "a successful browser test does not prove that a background service is protected". A curl request only tests curl's own trust bundle, so run the same request from the runtime your application uses, and expect a failure:

# Expect a certificate error. "OK" or a page means the client still trusts the intermediates.
curl -sS https://dv-g3b-emudhra.we-have-a-problem.com/ -o /dev/null && echo "STILL TRUSTED"

# Same test from Python (requests uses certifi's bundle)
python -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('STILL TRUSTED')"

What about the two code signing intermediates?

The two code signing intermediates, EM OV CS CA - G3B and G3C, were issued under emSign Root CS CA - G3, a root that the CCADB lists as included only by Microsoft. eMudhra revoked both on October 18, Microsoft blocked the certificates on October 20, and eMudhra says no end-entity certificate was issued from any of the eight.

Because nothing was issued from these two intermediates and no root program has announced removing emSign Root CS CA - G3, existing eMudhra code signing certificates are not known to be affected. The risk ran the other way: until the blocks, anyone holding these keys could in principle have issued a code signing certificate that chained to a Microsoft-trusted root. Our code signing guide explains how that chain of trust works on Windows.

What should certificate buyers take from this?

The lesson for certificate buyers is that your CA is a dependency you may have to change at a few days' notice, through no fault of your own. Customers here did nothing wrong, yet the root above them is going away within about ten days of the first report.

• Automate issuance. A team that renews through ACME or a script can move CAs in an afternoon; one that installs certificates by hand cannot.
• Know your chains. Keep a list of which root each certificate chains to, including certificates inside appliances and partner integrations.
• Keep CAA records current. They control which CAs can issue for you, and a stale record blocks an emergency switch.
• Check trust per program. A root can be included by one program and removed by another; our explainer on how certificate authorities are trusted shows how to read that.