Your CA Can Leave Before Your Certificates Do: eMudhra’s SSL/TLS Exit and the Case for CA Agility 

On October 17, 2026, a researcher reported that eight of eMudhra’s intermediate CA private keys could be recovered in under a second. Five days later, eMudhra’s board decided to leave the global SSL/TLS certificate business altogether. 

That is a certificate authority’s public TLS business going from incident to exit in less than a week. For the organizations holding roughly 30,000 affected eMudhra certificates, the question is no longer whether to change CAs. It is how fast they can do it. 

If this feels familiar, it should. Chrome announced its distrust of Entrust in June 2024, and within months Entrust had sold its public certificate business to Sectigo. Two very different failures produced the same outcome for customers: a forced CA migration on someone else’s timeline. This post covers what eMudhra announced, why waiting out the wind-down is not an option, what the Entrust and eMudhra cases have in common, and how CertSecure Manager’s one-click CA switch turns a CA migration into a routine change instead of a multi-week project. 

Key takeaways 

• On October 22, 2026, eMudhra announced it is exiting the global SSL/TLS certificate business, five days after eight weak intermediate CA keys were disclosed. Its signing, eSign, and enterprise public key infrastructure (PKI) businesses continue. 

• Chrome removes trust in the emSign ECC Root CA – G3 root on October 27, 2026, and Google has told site operators to install certificates from another PKI hierarchy immediately. 

• Chrome counted about 30,800 unexpired certificates chaining to that root as of October 21, 2026, almost all issued through InCommon, the higher education certificate service. 

• Entrust in 2024 and eMudhra in 2026 failed for different reasons, but both left customers with the same job: move every affected certificate to a new CA, fast. 

• CA agility, the ability to switch issuing CAs without outages, is now an operational requirement. CertSecure Manager’s one-click CA switch moves selected certificates to a new CA in bulk and redeploys them through automation. 

What eMudhra announced on October 22 

eMudhra is leaving the public SSL/TLS certificate market worldwide while keeping its other certificate and signing businesses. In its press release, eMudhra said SSL/TLS accounts for about 1% of its global revenue. It cited rising data sovereignty and compliance costs, competition from large providers that issue certificates for free, and social media scrutiny of the incident that it called “out of proportion” to the business. 

For customers, the release commits to four things: 

• eMudhra will contact affected customers and replace their certificates free of cost through partners during the transition. It has not named the partners or given an exit date. 

• Revocation and certificate status services will keep running until every issued SSL/TLS certificate has expired or been replaced. 

• Digital signature certificates, eSign, the emCA and CertiNext enterprise PKI platforms, the emSigner eSignature suite, and its identity products are not affected. 

• eMudhra will complete its remaining commitments to browser root programs, including a full root-cause report. 

The exit follows the October 17 disclosure we covered in our breakdown of the eMudhra CA key compromise: eight intermediate CAs, six for TLS and two for code signing, had P-384 private keys whose values were below 256, giving each key about 8 bits of randomness instead of 384. One key was simply the number 4. eMudhra says no end-entity certificates were issued from those eight intermediates and that its infrastructure was not breached. 

The root programs are not finished asking questions. According to The Hacker News, eMudhra told Mozilla on October 19 that certificate revocation lists (CRLs) it published in 2025 had been “resigned with flawed keys.” Chrome said this “raises serious concerns regarding eMudhra’s transparency and incident handling” and on October 21 posted 12 follow-up questions to the Mozilla incident ticket. 

Why eMudhra customers cannot wait for the wind-down 

The browser deadline arrives long before any orderly exit. Chrome removes trust in the emSign ECC Root CA – G3 root on October 27, 2026, and Mozilla decided on October 20 to remove the same root from Firefox. Google has told website operators with certificates chaining to that root that they “must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store.” 

Chrome counted about 30,800 unexpired certificates chaining to the ECC root in public Certificate Transparency (CT) logs as of October 21. Of those, 99.9% were issued through InCommon, the higher education certificate service created by Internet2. Those certificates were not issued by the eight weak intermediates. They are affected because they chain to the root being removed. Cornell University alone counts more than 300 affected certificates. 

Three details make this harder than “just renew”: 

• ACME renews on a schedule, not on demand: Chrome told eMudhra that standard Automated Certificate Management Environment (ACME) clients will not replace certificates outside their renewal window unless they support ACME Renewal Information (ARI, RFC 9773) or someone intervenes manually. eMudhra estimates about 97% of the roughly 30,000 certificates it needs to migrate were issued with ACME. Automated issuance does not mean automated migration. 

• A new hierarchy can mean new configuration: Moving from eMudhra’s ECC hierarchy to an RSA hierarchy may require client configuration changes, such as key type settings, on top of the reissue itself. 

• The fallback hierarchy is not a safe destination: eMudhra says its G1 RSA roots will keep serving customers until the transition is complete, and Mozilla said on October 20 that it is not removing trust in the G1 RSA root for now. But Chrome is still deciding whether to keep eMudhra’s remaining CA certificates, and the University of Michigan has warned that InCommon’s RSA certificates could be distrusted later. Reissuing onto another chain from the same CA could mean doing this work twice. 

After Entrust, eMudhra: the pattern enterprises keep relearning 

Public CAs keep leaving the market for different reasons, and every exit hands the same migration problem to the CA’s customers. The last decade has three clear examples. 

CA	What went wrong	What browsers did	What happened to the business
Symantec (2017 to 2018)	Repeated certificate mis-issuance and validation failures	Chrome phased out trust in Chrome 66 and Chrome 70 during 2018	Sold its website security business to DigiCert in 2017
Entrust (2024)	A pattern of compliance failures over six years, per Google	Chrome distrusted new certificates logged after November 11, 2024. Mozilla set a November 30, 2024 cutoff	Sold its public certificate business to Sectigo in early 2025
eMudhra (2026)	Eight intermediate CA keys generated with almost no randomness	Chrome and Firefox blocked the six TLS intermediates on October 17, 2026, and are removing the ECC root	Exiting the global SSL/TLS certificate business

Each exit had a different root cause: mis-issuance, compliance culture, and a broken key ceremony. What matters for enterprises is the trend in warning time. Symantec’s customers had more than a year of staged deadlines. Entrust’s customers had about four and a half months between Google’s June 27, 2024 announcement and the cutoff, which we covered in our analysis of Google’s move against Entrust and Mozilla’s follow-up decision. eMudhra’s customers have ten days between the disclosure and Chrome’s root removal. 

The scope of what stops working is changing too. Entrust’s distrust applied to newly issued certificates, so existing certificates kept working until they expired and customers had a renewal problem. eMudhra’s root removal reaches certificates already in production, so its customers have an outage problem. 

What CA agility actually requires 

CA agility is an organization’s ability to stop using one certificate authority and move every affected certificate to another without outages. It sits alongside crypto-agility and certificate agility, which we compared in our eMudhra key compromise post. In practice, CA agility takes four capabilities. 

1. Know where you depend on each CA 

You need a live inventory of every certificate, its issuing CA, its full chain including cross-signs, where it is deployed, and who owns it. CT logs only cover public TLS certificates. Internal, code signing, and client certificates need discovery of their own. 

2. Have a second CA ready before you need it 

An alternate CA is only useful if the account, integration, and domain and organization validation are already in place. Organization Validation (OV) and Extended Validation (EV) vetting takes time you will not have during an incident. 

3. Reissue on demand, not on schedule 

Renewal automation fires when a certificate approaches expiry. A CA exit needs the opposite: reissuing a chosen set of certificates from a different CA right now, regardless of where each one sits in its lifetime. 

4. Deploy and verify at the endpoint 

A reissued certificate that never reaches the server does not help. CA agility ends when the new certificate is installed, the correct chain is served, the service has reloaded, and the old certificate is gone. 

The CA/Browser Forum’s validity schedule makes these capabilities necessary anyway. Maximum TLS certificate validity has been 200 days since March 15, 2026, drops to 100 days on March 15, 2027, and reaches 47 days on March 15, 2029, as covered in our 47-day certificate validity guide. The automation that shorter lifetimes require is the same automation a CA switch depends on. 

Our take: make a CA switch a routine change, not a crisis 

Our view is that every enterprise should plan for at least one forced CA migration in the life of its PKI program. Symantec and Entrust were among the largest CAs of their time, so choosing a big CA does not remove the risk. Here is what we recommend: 

• Make time-to-switch a metric: If you cannot say how long it would take to move every public TLS certificate off your primary CA, measure it, and report it the way you report patch latency. 

• Run two public CAs: Keep at least one alternate public CA integrated, with validation current, and issue a small share of production certificates from it so the path stays tested. 

• Shrink your public CA footprint: Move internal-only services to a private CA you control, so a public CA exit only touches certificates that actually need public trust. Our guide to public CA vs. private CA covers where to draw that line. 

• Stop hardcoding chains: Pinned intermediates, bundled chain files, and trust stores that include a single CA turn a certificate reissue into an application release. 

• Rehearse with real certificates: A tabletop exercise is a good start. Switching a non-critical group of certificates to your alternate CA, end to end, is better. 

• Ask your CA about exit terms: Find out what happens to your certificates and prepaid subscriptions if your CA is distrusted or leaves the market. eMudhra’s offer of free replacements through unnamed partners is the kind of answer you want in writing before an incident, not after one. 

How CertSecure Manager turns a CA switch into one click 

CertSecure Manager, Encryption Consulting’s certificate lifecycle management platform, includes a one-click CA switch. You select the certificates tied to an outgoing CA and choose the target CA. CertSecure Manager then reissues them in bulk while renewal agents and enrollment protocols handle redeployment. The same bulk CA switching supports migrating to a new CA and moving to stronger cryptographic algorithms. 

• Find your exposure in minutes: Continuous discovery brings certificates from Microsoft, public, and private CAs into one inventory. Trust chain visualization shows the intermediates and roots each certificate depends on, so you can filter to an outgoing issuer instead of hunting through spreadsheets. 

• Switch in one click: Select the affected certificates and move them to the target CA in a single action, from a handful of certificates to thousands. 

• Redeploy without tickets: Zero-touch renewal agents for Apache, Nginx, IIS, Tomcat, F5 BIG-IP, Citrix NetScaler, JBoss EAP, and WildFly install the new certificate and reload the service. ACME, SCEP, EST, and REST APIs cover everything else. 

• Clean up what is left: Bulk revocation retires certificates still issued by the outgoing CA, and bulk ownership transfer reassigns certificates when teams change. 

• Stay CA-neutral: CertSecure Manager works across Microsoft CAs, public CAs, and private CAs, and organization-wide enrollment policies control which algorithms and key types each team can request. 

Here is what the eMudhra week looks like with and without a one-click CA switch. 

Step	Without CA agility	With CertSecure Manager
Find affected certificates	Query CT logs, email application owners, reconcile spreadsheets	Filter the inventory by issuer or chain
Choose a new CA	Procure, open accounts, and complete validation under deadline	Use an alternate CA already integrated in CertSecure Manager
Reissue	Wait for renewal windows or reissue certificates one at a time	One-click CA switch reissues the selected set in bulk
Deploy	Raise tickets, install manually, schedule restarts	Renewal agents and ACME install the certificates and reload services
Verify and clean up	Spot checks, with stragglers found when something breaks	Inventory shows what remains, and bulk revocation retires the old certificates

CertSecure Manager runs on-premises, in the cloud, or as SaaS. It integrates with ServiceNow, HashiCorp Vault, Azure Key Vault, Ansible, and SIEM tools such as Splunk and Datadog. 

Conclusion 

eMudhra will not be the last CA to leave the public TLS market. Symantec, Entrust, and now eMudhra show that the cause changes every time, the warning time keeps shrinking, and the migration work always lands on the CA’s customers. 

You cannot choose when your CA fails or walks away. You can choose whether moving off it takes one click or one quarter. Teams that know where they depend on each CA, keep a second CA ready, and can reissue and redeploy on demand will treat the next CA exit as a scheduled change rather than an outage. 

See a one-click CA switch on your own terms. Book a CertSecure Manager demo or start a 15-day free trial, and ask our team to walk you through a CA switch end to end. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 compliant. 

Not ready for a call? Paste any certificate into our free OpenSSL CSR and Certificate Decoder to check its issuer and key details in seconds. 

Frequently asked questions 

Why is eMudhra exiting the SSL/TLS certificate business? 

eMudhra announced on October 22, 2026, that it is leaving the global SSL/TLS certificate business, five days after eight of its intermediate CA keys were found to be weak. Its press release cites SSL/TLS being about 1% of revenue, rising data sovereignty and compliance costs, free certificates from large providers, and social media scrutiny of the incident. 

What should eMudhra SSL/TLS customers do now? 

Replace affected certificates with certificates from another PKI hierarchy before Chrome removes trust in the emSign ECC Root CA – G3 root on October 27, 2026. Google has told site operators to do this immediately. Check your ACME clients as well, because clients without ARI support will not reissue before their normal renewal window. 

Are eMudhra’s other products affected by the SSL/TLS exit? 

No, according to eMudhra. Digital signature certificates, eSign, the emCA and CertiNext enterprise PKI platforms, emSigner, and its identity products continue to operate. Revocation and status services for its SSL/TLS certificates also continue until every issued certificate has expired or been replaced. 

How is the eMudhra exit similar to the Entrust distrust? 

Both left customers needing a new CA quickly. Chrome distrusted Entrust for a pattern of compliance failures, with a November 11, 2024 cutoff for new certificates, and Entrust then sold its public certificate business to Sectigo. eMudhra’s trigger was a key generation failure, and its root removal affects certificates already in use. 

What is a one-click CA switch? 

A one-click CA switch moves a selected group of certificates from one certificate authority to another in a single action. In CertSecure Manager, the CA switch reissues the selected certificates in bulk from the target CA, and renewal agents or enrollment protocols such as ACME install them on the endpoints.