Research

eMudhra Revoked Eight More CAs It Told Mozilla Were Not Impacted. These Keys Are Not Broken; eMudhra Says It Cannot Show Where They Were

Patrick Duggan · · 6 min read

eMudhra Revoked Eight More CAs It Told Mozilla Were Not Impacted. These Keys Are Not Broken; eMudhra Says It Cannot Show Where They Were

If you run software that keeps its own list of trusted roots, check it for emSign Root CA - G1 and the other eMudhra roots this week, and do not rely on revocation checking to protect you. eMudhra has revoked eight more of its intermediate certificate authorities, the RSA siblings of the eight weak-key CAs we wrote about on October 23. On October 19 eMudhra told Mozilla those RSA CAs "went through a different path as per our assessment of the code and are therefore not impacted." That is no longer eMudhra's position. This is new information from eMudhra, not something our earlier post reported. That post, One of eMudhra's CA Private Keys Was the Number 4, described the incident as eight intermediates, which was the scope eMudhra and the browsers were working from at the time.

Which eight

eMudhra's full incident report, posted to Mozilla bug 2083449 on November 10, lists them with their fingerprints. All eight are RSA-4096 and were revoked on Saturday, November 7:

  • EM DV TLS CA - G2B and G2C
  • EM OV TLS CA - G2B and G2C
  • EM EV TLS CA - G2B and G2C
  • EM OV CS CA - G2B and G2C (code signing)

The six TLS CAs were issued by emSign Root TLS CA - G1. Certificate Transparency records on crt.sh show that root itself certified by the older emSign Root CA - G1. The two code-signing CAs were issued by emSign Root CS CA - G2. The B variants are eMudhra BV in the Netherlands and the C variants eMudhra Inc in the United States, the same split as the first eight.

Why eMudhra first said they were unaffected, and what changed

The report says all sixteen keys, eight RSA and eight elliptic-curve, came from one ceremony on April 30, 2025. The keys were generated correctly inside a hardware security module. A custom Python script then wrapped and unwrapped them as a rehearsal for moving them to another vendor's modules in the US and EU. For the elliptic-curve keys, one line of that script cut each private key down to its first byte, and the shortened copy, under an almost identical label, is the one that got certified. That is the failure from October.

For the RSA keys, eMudhra says the same script did not shorten anything, and the certified keys still match. But the script read the private key material out of the module and rebuilt the key from the copy held in the memory of the Python process on the ceremony computer. eMudhra writes that it "therefore cannot positively demonstrate that this key material was in compliance with CPS §6.2.6," the rule on moving private keys into and out of a cryptographic module. It also says later inspection of logs and files "cannot reliably establish or exclude how that material was handled."

So the RSA keys are not known to be compromised, and no one has shown them recovered. They are revoked because eMudhra cannot prove they stayed inside the hardware. eMudhra dates the finding to "early November 2026," from discussions with the browser root programs. On November 2 it posted to the bug that its earlier answers "were based on our analysis of what our internal teams could gather up until that point in time," including "which script pathways each set of keys went through."

Who is affected

The populations differ, and that matters for what you check.

  • The four G2B CAs issued no end-entity certificates, per eMudhra.
  • The four G2C CAs were in production. eMudhra's attached list has 195 rows: 130 from EM DV TLS CA - G2C, 63 from EM OV TLS CA - G2C and 2 from the code-signing EM OV CS CA - G2C. Our count is from that spreadsheet. eMudhra says affected customers have been moved to new certificates. In the same list, 107 of the 195 are marked revoked and the rest are blank or "N/A."
  • Issuance continued after the doubt surfaced. The last certificate from EM OV TLS CA - G2C was issued on November 3 at 13:48 UTC, the day after eMudhra withdrew its earlier answers. The last code-signing certificate from EM OV CS CA - G2C was issued on October 7.

eMudhra revoked these eight with the reason "cessation of operation," not "key compromise." Participants in the Mozilla thread have asked why. The reason code matters to software that treats the two differently, and to anyone deciding whether to distrust signatures made before the revocation date.

What the browser and OS vendors have done

  • Chrome and Firefox: eMudhra's incident page lists November 16, 2026 as the date after which certificates from the G1 hierarchy are no longer trusted. eMudhra says all issuance from emSign Root CA - G1 stops before then. Its remaining customer there is a North American university federation being moved to another provider.
  • Microsoft: its response post, updated November 10, says Windows will remove the remaining 10 eMudhra roots through automatic trust updates on November 16. The post does not mention the RSA intermediates.
  • Apple: its support note, published November 9, says macOS 27.2.1, 26.7.3 and 15.8.3 stop curl, git, python3, ruby, perl and openssl from accepting the compromised certificates. Those updates also remove five eMudhra and related roots from the command-line trust file, /etc/ssl/cert.pem, including emSign Root CA - G1. Separately, eMudhra's incident page lists November 30, 2026 for Apple's removal of the G1 root.

What to do

  1. Update the operating systems first. On Macs, install macOS 27.2.1, 26.7.3 or 15.8.3. Until you do, the command-line tools trust the old file. We checked the laptop we wrote the October post from, still on macOS 27.0.1. Its /etc/ssl/cert.pem still contains emSign Root CA - G1, emSign ECC Root CA - G3 and AAA Certificate Services, and its system curl still returned HTTP 200 on two of the October test hosts today.
  2. Find the trust stores that do not update with the OS. These are the same places as last time: Java keystores, Python virtual environments and certifi bundles, old container base images, appliances and embedded devices. Look for emSign Root CA - G1 and emSign Root CS CA - G2 in them, as well as the G3 roots from October. A revoked intermediate protects only clients that check revocation, and many of these do not.
  3. Code signing: if your allow-listing or EDR trusts signers by chain, look for binaries signed under EM OV CS CA - G2B or G2C. eMudhra's own list has two certificates under G2C. The keys are not shown to be compromised, so this is a review, not an alarm.
  4. If you hold a certificate from a G2C CA and eMudhra has not replaced it, replace it now. The issuing CA is revoked.
  5. Blocklists built by hand: add the eight new SHA-256 fingerprints from Appendix C of eMudhra's report, comment 82 on bug 2083449. Copy them from the source, not from a summary. As we noted in October, one name can belong to more than one certificate.

What is not known

Whether anyone copied the RSA key material while it was in host memory. eMudhra says it cannot establish that either way, and KPMG's independent review is due December 4. Whether the elliptic-curve keys from October were used against any client that skips Certificate Transparency checks. eMudhra says it knows of no misuse, and Mozilla's investigator has said anyone holding those keys could have impersonated any website. Whether more of eMudhra's keys are affected: the report says the A and A-1 series were generated on a different platform and did not go through the transfer script, and that their private keys "have not been recoverable."

How we know, and how we checked

We read eMudhra's full incident report (comment 82 on Mozilla bug 2083449), its October 19 answer (comment 11) and its November 2 note (comment 73) through Bugzilla's public interface. We counted the attached certificate spreadsheet (comment 83) ourselves. We read eMudhra's incident page, last updated November 5, Apple's support note 149555, Microsoft's MSRC post and the tracking site run for the incident, and we looked up the DV G2C intermediate's issuer on crt.sh. We checked our own Mac's trust file and two test hosts from the October post. There are no test hosts for the RSA CAs, so we did not test them. Our edge instruments cannot see this: it is a question of what your software trusts, not of traffic. We add nothing to our feed. Certificate fingerprints belong in trust-store blocklists, not IP or domain blocklists, and no network indicators were published in the sources we read.

Sources

Mozilla Bugzilla bug 2083449: eMudhra full incident report (comment 82, November 10, 2026), certificate list (comment 83), earlier response (comment 11, October 19, 2026), November 2 note (comment 73). eMudhra, Certificate Security Incident page, last updated November 5, 2026. Apple, support note 149555, November 9, 2026. Microsoft MSRC, response to compromised eMudhra certificate authority keys, updated November 10, 2026. crt.sh entry for EM DV TLS CA - G2C. The Hacker News report on the eight additional revocations (thehackernews.com/2026/11/emudhra-revokes-8-more-cas-it.html), November 2026, read after the primary sources.

Five percent of this is wrong somewhere. It always is.

Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com