eMudhra Exits Global SSL Business After Browser CA Blocks

Whenever a Certificate Authority lands in the security news, my first instinct is to open a terminal and check what is sitting on our load balancers. This week, the company in the hot seat is eMudhra.

On Thursday (October 22), the Indian digital trust provider decided to shut down its global SSL/TLS certificate business altogether. That announcement came just five days after an independent researcher named Wayne noticed something wild about eight of eMudhra's intermediate CA certificates: their private keys were tiny enough to brute-force in milliseconds.

I mean literally tiny. All eight private keys were integers under 256, and one of them was just the number 4.

Once Mozilla, Google, Apple, and Microsoft got the report, they moved fast to block those certificates. Now eMudhra is walking away from public TLS issuance for good. If you have any production services using certificates chained back to eMudhra's ECC root, you have until October 27 to swap them out before Chrome starts rejecting connections.

How a public CA ends up with a private key of 4

Intermediate CAs do the heavy lifting in public key infrastructure. If someone figures out an intermediate CA's private key, they can sign valid TLS certificates for any domain they want.

So how did a key of 4 get past the gates? In their post-mortem, eMudhra traced the mess back to an April 30, 2025 Key Generation Ceremony. Their engineers were using FIPS 140-2 Level 3 HSMs, but a faulty script during a key wrap/unwrap step accidentally spat out a second batch of tiny keys alongside the real ones. Those broken keys got exported and baked into eight public intermediate certificates.

Why eMudhra decided to just walk away

What really stings is that those eight intermediates sat in public trust stores from mid-2025 and passed two separate audit cycles before Wayne spotted the math error on October 17. To eMudhra's credit, they revoked all eight intermediates within 14 hours of getting the heads-up. Seven of them were never used in production, and the eighth never signed a single customer certificate.

Even so, eMudhra's share price fell 36% in two days. Since global SSL/TLS only brought in about 1% of their total revenue anyway, their board decided to quit the global TLS market, keep their Indian eSign and enterprise PKI tools running, and hand out free partner replacements to affected SSL buyers.

Why 30,800 live certificates are still breaking

If none of the eight weak intermediates ever signed a website certificate, why do ops teams still have a mess to clean up this weekend?

Because the browsers did not stop at blocking the eight bad intermediates. They also pulled the plug on the parent root certificate sitting above them: emSign ECC Root CA - G3.

The October 27 Chrome cutoff

Mozilla pushed a OneCRL block to Firefox users less than three hours after getting the Saturday report, and they are stripping the G3 root out of NSS 3.131.1. Google blocked the TLS intermediates too, and starting the morning of October 27 (Pacific time), Chrome will distrust the whole emSign ECC Root CA - G3 chain.

Based on public Certificate Transparency logs, roughly 30,800 unexpired certificates chain up to that G3 root. Almost all of them belong to universities using InCommon, which moved its certificate backend onto eMudhra's CertiNext platform earlier this year. For now, eMudhra's separate RSA root (emSign Root CA - G1) is still trusted in browsers.

What to check on your servers before Tuesday

Do not just search your email for an eMudhra invoice and assume you are fine. Because partner platforms like InCommon sit in the middle, plenty of teams run certificates chained to eMudhra without knowing it.

nspect the live chain and force ACME reissues

Run openssl s_client -connect yourdomain.com:443 -showcerts against your live domains. If emSign ECC Root CA - G3 shows up in the chain, you need a new cert before Tuesday across every corner of your product's network, including staging boxes, VPNs, API gateways, and mail relays.

Do not count on Certbot or cert-manager to save you automatically, either. Normal ACME renewal jobs only look at expiration dates. If your cert still has two months left on it, your cron job will happily do nothing while Chrome kills the root underneath it. Force a manual reissue with another CA, and get QA to test your webhooks and API clients once the new chain is live.

Stop locking your stack to a single CA

We already lived through root removals with Symantec, TrustCor, and Entrust. Working as an enterprise IT delivery partner, we treat CAs just like DNS providers: we assume any single vendor can have a bad week and get distrusted on short notice.

Whenever we build Managed DevOps, DevSecOps, and AIOps pipelines at iDefender, we keep certificate issuers decoupled in code so flipping over to Let's Encrypt, Sectigo, or DigiCert takes five minutes instead of a weekend outage. If you want help auditing your certificate chains or automating renewals before the browser cutoff hits, talk to our team and check your SSL today.