A CA Just Quit the TLS Business. Check Your Chain

eMudhra is exiting public TLS certs. Your certs depend on a company staying alive — here's how to audit and de-risk them today.

Dafallah Ibrahim

— 2 min read
Share

eMudhra, a public certificate authority, just announced it's exiting the global SSL/TLS certificate business. If you've never heard of them, don't click away — somewhere in your stack, a load balancer, managed database, or vendor endpoint is holding a cert chained to a CA that decided to stop being a CA.

This is the latest lurch in a shaky market: Symantec was distrusted in 2018, Entrust in 2024, and Let's Encrypt once revoked millions of certs over a validation bug. The failure mode is never dramatic. It's a renewal that quietly stops working.

Why this matters

We track library versions down to the patch, then treat TLS certs as plumbing. A certificate is a dependency on a company staying in business, passing audits, and meeting revocation SLAs. When that stops, current certs keep working — your ability to replace them doesn't. An unrenewable cert has a hard deadline: expiry day is an outage you scheduled months in advance.

How it works

Trust flows from your leaf cert through an intermediate to a root sitting in OS and browser trust stores. A business exit usually means issuance stops while existing certs ride out their validity. The tail risk: if roots get pulled from trust stores — wind-down, acquisition, failed audit — every cert chaining to them fails at once. No revocation required.

Migrating means reissuing from another CA and serving the new full chain. The part that bites: clients that pinned or bundled the old intermediate. mTLS peers, mesh configs, and mobile apps routinely carry the old chain around, so "we rotated the cert" doesn't finish the job.

Where this helps

  • Load balancer fleets. Multi-year certs with automation pointed at one CA account are the classic silent casualty.
  • mTLS meshes. Peer configs often embed the CA bundle; reissuing leaves without updating peers produces confusing handshake failures.
  • Embedded devices. A frozen root store can't learn to trust a new CA without an update path you should have shipped already.
  • Vendor endpoints. Managed databases and SaaS tools hide their CA from you. Ask for migration docs now, not mid-incident.

Watch out

Don't mass-reissue in a panic — rotating chains fleet-wide in a hurry is how you break things at scale. Do configure a second issuer before you need it: cert-manager supports multiple ClusterIssuers, and switching a Certificate's issuerRef is a one-line change. If any of your apps pin certificates, know that pinning turns a CA transition from an ops task into a release.

Try it yourself

# Inventory issuer + expiry for every TLS endpoint you own
for host in api.example.com cdn.example.com vault.internal; do
  echo "== $host"
  echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -issuer -enddate
done

Anything showing an unexpected issuer or an expiry inside your next two sprints goes on the migration list.

TL;DR

  • What changed: eMudhra, a public CA, is leaving the global TLS certificate business.
  • Why it matters: certs are a dependency on a company's survival, and renewal pipelines die quietly — Symantec and Entrust already proved it.
  • Try today: run the openssl loop over your endpoints, then wire up a backup ACME issuer.

Read more