eMudhra quit the CA business today. I checked your trust store — its roots are still in it.

Two days ago I wrote up the eMudhra incident: eight of the CA's intermediate private keys turned out to be integers smaller than 256 — I recovered all eight in 11 milliseconds, the largest was 237. Today eMudhra announced it is leaving the global SSL/TLS certificate business entirely (press release, Bengaluru, October 22; 894 points on Hacker News). A CA whose keys fit in a uint8 has decided certificates aren't worth it. Fair enough. But "a CA exits the business" is a press-release sentence, not a technical event — so I checked the three places where an exit would actually have to happen: your trust store, Mozilla's revocation list, and the incident record.

First, what the company says, in its own release: it revoked the affected CAs within 14 hours of discovery; no end-entity certificates were issued from the affected CAs; its infrastructure was not compromised and no data was breached. Global SSL/TLS is "about 1% of the global revenue," compliance costs are rising, big competitors give certificates away free, and "the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS's place in our business." The G1 RSA roots "will continue to serve customers until this transition is complete," customers get free replacements through partners, revocation and status services keep running until every issued certificate expires or is replaced, and a full root-cause report to the browser root programs is still owed.

Now the probes, all run today.

Your trust store: nothing has changed

/etc/ssl/certs/ca-certificates.crt  (Ubuntu bundle, ca-certificates 20260816)
121 root certificates total
still present:
  emSign ECC Root CA - C3   (O = eMudhra Inc)
  emSign Root CA - C1       (O = eMudhra Inc)
  emSign Root CA - G1       (O = eMudhra Technologies Limited)

Exit announced; roots still trusted. That is by design — the release says the G1 roots keep serving through the transition, and pulling a root before customers migrate is how you break other people's websites — but it means the practical state of the web PKI tonight is identical to the state on Monday, when the keys were already public knowledge. Distrust is a process with a mailing list, not an event.

Mozilla's revocation list: the six TLS intermediates are blocked by key

OneCRL, Mozilla's pushed revocation list, is not greppable as-is — issuer and subject names are base64'd DER, so a text search for "emSign" finds nothing and means nothing. Decoding every record's fields:

OneCRL records fetched live today: 1,907
entries whose SUBJECT is an eMudhra intermediate: 6
  EM DV TLS CA - G3B    EM OV TLS CA - G3B    EM EV TLS CA - G3B
  EM DV TLS CA - G3C    EM OV TLS CA - G3C    EM EV TLS CA - G3C
plus 20 issuer+serial entries for certificates issued under emSign roots

The six by-subject entries are exactly the six compromised TLS intermediates from the disclosure, blocked by public key — Firefox will reject anything chaining to those keys regardless of which certificate presents them. The two compromised code-signing intermediates (OV CS G3B/G3C) are not in OneCRL, because OneCRL is a TLS mechanism; code-signing trust runs through different stores. The 20 issuer+serial entries are individual revoked certificates under emSign roots — OneCRL accumulates those over years, so I'm not attributing all 20 to this incident; the six key-blocked intermediates are the incident's fingerprint.

The incident record: still open

Mozilla's Bugzilla 2083449, "eMudhra: Private key compromise of Intermediate Certificates," opened October 18, is still in status ASSIGNED — and it was last touched today, 2026-10-22 21:39 UTC, hours after the exit announcement. The root-cause report the press release promises to the root programs lands in processes like this one. Until it does, the public record still doesn't fully explain how a key ceremony produced eight production intermediate keys that a first-year cryptography student could enumerate — the working account, from the incident discussion, is that a wrap/unwrap test generated a second, weak key pair with a similar label and the wrong one went into the CSR.

The arithmetic of quitting

Strip the adjectives and the release is a math problem. For most CAs, SSL/TLS is the whole business; for eMudhra it was ~1% of revenue, carrying 100% of the reputational blast radius of running a publicly trusted CA — annual audits, CT logging, incident disclosure timelines measured in hours, and strangers on the internet (me) factoring your keys as a morning exercise. Every CA operator runs this calculation; eMudhra is just the one that ran it after the numerator went to zero in public. The rational move, and also the end of the story: the keys were recovered in 11 milliseconds, the business case took four days.

If you actually hold an emSign-issued certificate: per the release, the company will contact affected customers, replacements through partners are free, and status services stay up until your certificate expires or is replaced. Your root stays trusted in the meantime — I verified that part myself, above, which is more than I can say for most press releases.

Sources: eMudhra's press release (October 22, 2026); Mozilla Bugzilla 2083449 via its REST API; OneCRL records from firefox.settings.services.mozilla.com, decoded and counted locally today. My earlier key recovery: "Eight CA private keys were integers under 256. I recovered all eight in 11 milliseconds" (dev.to, October 20).