<summary-box>eMudhra announced it will exit the global SSL/TLS certificate business. Mozilla’s public incident record also documents recovery of compromised private keys for eight eMudhra intermediate certificates and a resulting trust response for the affected ECC G3 path. If you run public websites, APIs, mail, VPN, mobile backends, or partner-facing services, the key task is not panic — it is verification. The safest approach is to identify the exact issuer chain in use, confirm whether you are on the affected ECC G3 path or the separate G1 RSA transition path, and stage a replacement before you remove anything old.</summary-box>
What changed, and what did not?
On October 22, 2026, eMudhra announced that its Board decided to voluntarily withdraw from the global SSL/TLS certificate business. In the company’s statement, it said the segment contributes about 1% of global revenue. The same statement says its G1 RSA roots will continue to serve customers during the transition, affected customers will be contacted, free replacement certificates from partners will be offered, and revocation/status services will continue until issued certificates expire or are replaced. These are eMudhra’s claims and transition plans, not independent guarantees.
At the same time, a public Mozilla Bugzilla incident records compromise and recovery of the private keys for eight eMudhra intermediate certificates: six TLS intermediates and two code-signing intermediates. Mozilla’s incident discussion says the affected P-384 private-key integers were below 256 and could be recovered almost instantly; that detail comes from Mozilla’s public incident record. Mozilla deployed OneCRL revocation for the affected intermediates and later decided on emergency removal of trust in emSign ECC Root CA - G3. A Chrome Root Program comment in the same incident discussion says Chrome Root Store v43 was expected to land in Stable Tuesday morning, October 27, 2026 PDT. Treat that as an expected rollout, not a universal instant deadline, because client rollout timing can vary.
What is not affected, according to eMudhra’s statement, includes India DSC/eSign, enterprise PKI products such as emCA and CertiNext, emSigner, SecurePass, and emAS. Do not assume all eMudhra products are shutting down, and do not assume a browser success test on one device proves every client is safe.
Quick definitions for the checklist
- CA (Certificate Authority): the organization that issues digital certificates and signs them so browsers and other clients can trust them.
- Intermediate certificate: a certificate used by the CA to sign end-entity certificates; it sits between the root and the server certificate.
- Root store: the trusted root certificates built into a browser, operating system, or device.
- Certificate chain: the full path from your server certificate up through intermediates to a trusted root.
- CRL (Certificate Revocation List): a published list of revoked certificates that clients may check.
- OCSP (Online Certificate Status Protocol): a live status check that asks whether a certificate is still valid or revoked.
Who should act now?
| Situation | Action | Urgency |
|---|---|---|
| Confirmed ECC G3 chain | Treat as high priority; verify exposure and prepare replacement immediately | High |
| G1 RSA customer | Keep services running, but confirm the exact chain and arrange transition/replacement | Medium |
| India DSC/eSign-only customer | No TLS migration required from this incident alone | Low |
| Uncertain or reseller-supplied certificate | Identify issuer chain now and ask the reseller for details | High |
8 checks before you change anything
1) Identify whether you bought or received an eMudhra public TLS certificate
Start with procurement records, certificate management tools, ticket history, and reseller emails. Look for eMudhra, emSign, or a reseller that may have supplied the certificate indirectly. If you only use India DSC/eSign or enterprise PKI products for internal identity workflows, you may not be in scope for this TLS change.
2) Inventory every public endpoint and the full chain
Do not stop at the main website. Inventory CDN endpoints, load balancers, APIs, mobile backends, mail systems, VPN portals, and partner-facing services. Include staging if it is publicly reachable. The issue often hides in one forgotten hostname or a service managed by a different team.
3) Verify issuer, intermediate, and root — not just the brand name
A certificate can say “eMudhra” and still be on a different trust path. Use a command such as:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
Inspect the leaf certificate, the intermediate certificate(s), and the issuing root. Look for whether the chain goes through emSign ECC Root CA - G3 or through the G1 RSA path. If you are unsure, save the output and compare it with the certificate details in your browser, CDN, or load balancer console.
4) Separate the affected ECC G3 path from the G1 RSA transition path
Do not assume one browser result proves the whole environment is fine. A browser on one laptop may already carry a new trust decision while older managed devices, Java runtimes, Android builds, iPhones, Windows images, or embedded clients behave differently. Also, the G1 RSA transition path is not the same as the affected ECC G3 path.
5) Contact eMudhra or your reseller for the replacement terms
Ask for the exact replacement root, issuance deadline, revocation date, and refund or renewal terms. If the certificate came through a reseller, involve them too. The sources reviewed did not publish a precise universal customer migration-completion date or a complete partner list, so do not rely on a guessed deadline.
6) Obtain and stage an alternative certificate before removal
Get the replacement ready before you touch the current one. If your platform supports ACME or another automation path, prefer it. Stage the new certificate, key, and chain in a test or canary environment first, then plan a controlled cutover with rollback.
7) Test major clients, not just one browser
Check major browsers plus Java, Android, iOS, Windows, OpenSSL, curl, and older managed devices. Revocation behavior and trust-store update timing differ by platform. A certificate may appear valid in one place and fail in another because the chain, root store, or revocation checking differs.
8) Deploy with monitoring and rollback
After cutover, verify chain order, SNI behavior, expiry alerts, synthetic tests, OCSP/CRL reachability, and certificate transparency monitoring. Keep a rollback path ready in case an intermediate is misordered, an old client cannot validate the new chain, or a partner endpoint still expects the previous chain.
A short practical read on the incident itself
Mozilla’s incident record matters because it drives how some clients and root programs respond. But the operational question for most teams is narrower: which endpoints are actually using an affected chain, which are on the separate G1 RSA path, and which are unrelated to this incident altogether? That is why verification should come before replacement. If you move too early without checking chain dependencies, you can break older clients. If you move too late, you risk trust failures when browser and root-store updates land.
Do you need to migrate an eMudhra TLS certificate now?
Do You Need to Migrate an eMudhra TLS Certificate Now?
FAQ
Will every eMudhra certificate fail on October 27?
No. The Chrome Root Store timing noted in Mozilla’s incident discussion is an expected rollout for one browser ecosystem, not a universal instant deadline for every client. Other platforms update on their own schedules.
Is the entire eMudhra portfolio shutting down?
No. eMudhra said India DSC/eSign, enterprise PKI products, emSigner, SecurePass, and emAS are unaffected. The TLS exit is narrower than the company’s full product lineup.
Should I rely on the company statement alone?
No. Use eMudhra’s statement for what the company says it plans to do, and use browser/root-program and client-side testing to confirm how your own services behave in practice.
What is the safest next step?
Inventory your public endpoints, confirm the exact certificate chain, contact your issuer or reseller, and stage a replacement before you make the switch. If you already know you are on the affected ECC G3 path, treat this as a priority work item today. If you are on the G1 RSA path, keep monitoring while you arrange the transition.
Sources
- eMudhra exit press release: https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business
- eMudhra statement on the incident: https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca
- Mozilla public incident record: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
- eMudhra stock-exchange filing PDF: https://emudhra.com/investor-assets/investors/esg-profile/fy2027/emudhra-to-exit-global-ssl-tls-certificate-business.pdf
- Current demand context: https://news.ycombinator.com/
Conclusion
This is a trust-chain change, not a reason for alarm. The teams most likely to avoid trouble are the ones that verify the issuer path first, replace certificates in a controlled way, and test across the full client mix before and after cutover. If you handle public TLS for any customer-facing service, use the next 24 hours to confirm whether you are on the affected ECC G3 path, on the separate G1 RSA transition path, or outside the incident entirely.
