What happened

On October 17, 2026, a researcher reporting as Wayne ran Google's open-source paranoid_crypto checks against public CA certificates and found eight eMudhra intermediates whose P-384 private keys were tiny. Mozilla's Dennis Jackson summarized it in the incident bug: "The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte." Scott Helme published the values: one key is the number 4, another 56, another 115. Six of the intermediates were for TLS and two for code signing. They had been created in April 2025 and were also cross-signed by Sectigo's AAA Certificate Services root.

The response was fast. Chrome blocked the keys through a CRLSet update within about two hours of the report, Mozilla independently recovered the keys and pushed a OneCRL block the same evening, and eMudhra revoked all eight on October 18, with Sectigo revoking its cross-signs on October 19. Go added the keys to a denylist in crypto/x509 (CVE-2026-111943, fixed in Go 1.27.3 and 1.26.10), and Mozilla's checker site reports that Microsoft and Apple block them too. eMudhra says the intermediates never issued real certificates and blames a key ceremony test in which "a flaw in the code resulted in the second pair of keys being created onboard which were weaker," and those keys were then used by mistake. Google says no TLS certificates chaining to the six intermediates had been logged to certificate transparency before it blocked them.

The trust question did not stop at the intermediates. Mozilla removed emSign ECC Root CA - G3 from NSS on October 20, and Google said website operators with certificates chaining to it "must immediately acquire and install a new TLS certificate from another PKI hierarchy," with Chrome's root store dropping it on October 27. According to the Mozilla bug, about 30,800 unexpired certificates chain to that root, and 99.9% of them were issued through two InCommon intermediates, InCommon Intermediate CA - OVG3C and DVG3C, which universities and research organizations use. On October 22, eMudhra announced it would "voluntarily withdraw from the global SSL/TLS certificate business," while moving customers to its emSign Root CA - G1 (RSA) hierarchy. It has not given an end date.

Why it matters if you run public infrastructure

A certificate that chains to a removed root breaks in stages, which is what makes it easy to miss. Firefox and software that uses Mozilla's trust store (most Linux distributions, Python's certifi) already reject it; Chrome and Android follow on October 27; other software keeps accepting it until its bundled root store is updated. A monitoring check that validates the chain with an older bundled store will say everything is fine right up until your users start seeing errors. And because 97% of eMudhra's certificates were issued by ACME, many of them sit on hosts where nobody has looked at a certificate since the automation was set up.

What to check this week

  1. Find certificates issued by eMudhra or through InCommon's OVG3C and DVG3C intermediates on every host you run, including mail servers, VPN portals and API endpoints. Look at the full chain, not just the leaf issuer: openssl s_client -connect host:443 -servername host -showcerts shows every certificate the server sends.
  2. Replace them before October 27 with a certificate from a different hierarchy, and deploy it everywhere the old one is served (load balancers, CDNs, appliances). eMudhra's own migration path is its emSign Root CA - G1 hierarchy; any other public CA also works.
  3. Point your ACME clients at the new CA. Renewal automation will otherwise keep fetching certificates from the old hierarchy.
  4. Update trust stores on your own clients: ca-certificates, certifi, Node.js, Go (1.27.3 or 1.26.10) and any Electron apps, so your outbound connections stop trusting the compromised CAs too.

How Attack Surface Scan covers this

Attack Surface Scan now checks every certificate in the chain a host serves against a list of CAs the browser root programs have blocked or removed, matched the way Chrome and Go match them. A chain through one of the eight compromised intermediates raises tls.compromised-ca at critical severity; a chain to emSign ECC Root CA - G3 raises tls.distrusted-ca at high. This matters because our ordinary validation, like most software, uses a bundled root store that still trusts that root. The check runs on every host under your verified domains, including hosts found through certificate transparency logs, and on extra ports such as mail. See how we check for new vulnerabilities and CA incidents for the details.

Sources