Your Certificate Authority Quit. Here’s What That Says About How You Manage Trust
Last week we made the case that the front door to your network is no longer the front door. Verizon’s 2026 Data Breach Investigations Report put vulnerability exploitation ahead of stolen credentials for the first time, and the advice was unglamorous: know what you run, patch it, turn off what you don’t need.
There is a second door most security inventories never list. It is not a firewall or a VPN. It is the certificate authority.
On October 22, eMudhra, an Indian certificate authority that had issued more than 60 million digital certificates, announced its board had decided to withdraw from the global SSL/TLS certificate business entirely. Five days earlier, a researcher named Wayne had reported to Apple, Google, Microsoft, and Mozilla that eight of eMudhra’s intermediate CA certificates had private keys so weak they could be recovered from the public certificates in under a second.
One of those keys was the number 4.
The Key Was Public From Day One
Scott Helme, one of several researchers who independently recovered the keys, put it plainly: normally when a CA key is compromised, someone stole it, and you can reason about who has access now. Here nobody had to steal anything. The key was effectively public from the day the certificate existed.
According to Mozilla’s incident report, the eight affected intermediates came from a batch of 24 generated on April 30, 2025. The private keys were meant to be random numbers over 100 digits long. Each of the eight was smaller than 256. Testing at most 256 candidate values found the match. Helme’s recovered values included 4, 56, and 115.
EMudhra’s own explanation, given on Mozilla’s bug tracker, was worse than the numbers. A faulty script during the key ceremony had generated a second set of weaker keys, and their labels resembled those of the properly generated ones, so staff preparing the certificates picked the weak ones. Nobody noticed for seventeen months. A routine ceremony, a labeling mix-up, and a set of keys brute-forceable in a fraction of a second sat in production trust chains until a researcher stumbled across them querying the Common CA Database.
The Part That Is Still Open
Browsers moved fast. Chrome and Firefox blocked the affected intermediates on October 17, the day of the report. Apple followed on the 19th, Microsoft on the 20th. eMudhra revoked all eight on the 18th, and Sectigo revoked the cross-signed copies by the 19th.
Chrome did it without touching your browser. Rather than pushing a browser update, the Chrome Root Program landed a CRLSet block keyed on the Subject Public Key Info hashes of the affected CAs at 19:45 UTC, ninety minutes after the report arrived. Because CRLSet blocks by SPKI, every certificate sharing those keys was rejected instantly, no restart required.
Then the root itself started leaving. Mozilla emergency-distrusted emSign ECC Root CA – G3 on October 20. Chrome removes the same root from the Chrome Root Store on the morning of October 27, Pacific time, and told site operators with certificates chaining to it to install a new certificate from another hierarchy immediately. The Chrome Root Program confirmed it had found no other keys with the same entropy failure in its own root store.
About 30,800 unexpired certificates chained to that root as of October 21, by Chrome’s count of public Certificate Transparency logs. Nearly all came from InCommon, the certificate service Internet2 built for higher education, which migrated onto eMudhra’s CertiNext platform between April and July. InCommon told subscribers to reissue as RSA while ECC issuance was restored, and said eMudhra would stop issuing from any intermediate chained to its public roots within thirty days of October 22. Removal causes breakage because the root was trusted by Chrome, Mozilla, Apple, and Microsoft in the first place. Pull it and legitimate sites break alongside any fraudulent ones.
Where Small Businesses Actually Get Burned
If you run a web presence, a VPN, a mail server, a load balancer, a partner integration, or anything that authenticates with certificates, you are in scope whether or not you have ever heard the word “eMudhra.”
The browser is the only part of your stack that got a clean answer. Kudelski Security’s advisory spells out the exposure that remains: non-browser TLS clients, developer tools, software that bundles its own trust stores, Python packages, containers, unpatched Linux distributions, embedded devices, and VPN clients. Go binaries built with versions older than 1.27.3 or 1.26.10 need to be rebuilt. Python’s certifi bundle was patched in 2026.10.19, Alpine’s ca-certificates in 20261020-r0. And on macOS, the built-in curl utility does not check revocation information, so it may keep trusting affected certificates that every browser on the same machine has already rejected.
The automation is the trap. eMudhra estimates roughly 97 percent of the affected certificates were issued through ACME, the protocol that renews certificates automatically. Google told site operators that standard ACME clients do not replace certificates outside their renewal window unless they support ACME Renewal Information, or unless a human steps in. Certificate lifecycle management will happily renew the same broken certificate on the same broken chain.
That is the compliance lesson hiding inside the incident, and it generalizes past certificates. You do not get to delegate trust and then stop inspecting it.
Five Things To Do This Week
1. Inventory every certificate you own and who issued it. Run `openssl s_client -connect yourdomain.com:443 -showcerts` against each public hostname and look for “emSign” or “eMudhra” in the chain. Do not stop at the website. Check the load balancer, the mail server, the VPN appliance, every partner API you call, and every internal service that presents a certificate. Write the results down with an owner and a renewal date next to each one.
2. Test the runtimes, not just the browser. The researcher’s disclosure site hosts test endpoints serving certificates from the compromised chains. Hit them from each environment you operate: your server, your container, your CI runner, your laptop. `curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/` returning a certificate verification error means that client correctly distrusts the chain. A successful connection means it still trusts it.
3. Update every trust store you own, including the ones you forgot about. System CA bundles first. Then the language-level ones buried in your dependency tree: Python’s certifi, Node’s bundled roots, Rust’s webpki-roots, Electron, and anything your vendor ships in a container base image. Rebuild images from patched bases rather than restarting running containers, then confirm the rebuild changed the bundle.
4. Never fix a certificate error by disabling verification. Cloudflare made this point explicitly in its own incident writeup, and they had to walk their own estate for the same reason. The temptation when a certificate breaks in production is to turn off the check that caught it. That turns a visible outage into a silent hole.
5. Add a trust-store dependency check to your pipeline. Endor Labs suggests scanning source trees and image filesystems for bundled PEM certificates and comparing fingerprints against the four affected roots. Make that a CI step that fails a build. The point is not to catch this incident. The point is to make sure the next upstream decision, from any CA or vendor, does not quietly become your outage.
The Closing Argument
Certificate authorities are the least examined vendors in your business. You have a relationship with your managed service provider, a renewal date for your security software, and someone who notices when the office internet drops. Your CA has none of that. It issues credentials the entire ecosystem treats as ground truth, from ceremonies you never see, and until this month there was no mechanism that flagged a generation bug for seventeen months.
CRLSet, Certificate Transparency, and root store review turned a catastrophic scenario into a Tuesday morning cleanup. But the system only worked because multiple independent parties were watching: a researcher running a CCADB query, a separate researcher reversing the math, a browser vendor, a CA, a hosting provider, and a university network. No single one of them had a job title that said “protect small businesses from certificate authorities.”
Your job this week is to be one of those parties for your own estate. Find out who signed your certificates, what still trusts them, and whether the answer is written down anywhere or lives in the head of whoever set up the server three years ago. If it is the second one, you have already found your problem.
