eMudhra announced its withdrawal from the global SSL/TLS certificate business on October 22, 2026. The announcement follows the compromise of eight intermediate CA certificates. Website, API and VPS operators have two separate tasks: replace chains that will lose trust and update clients still accepting the compromised keys.
Information reviewed October 22, 2026. We distinguish the provider's announced plan, browser protections and application updates. This is not an audit of customer servers.
October 22: eMudhra announces its exit from SSL/TLS
In its October 22 statement, eMudhra announced a voluntary withdrawal from the global SSL/TLS certificate business. This is not a closure of all its services or an immediate end to customer support: according to the company, its G1 RSA roots will continue serving customers during the transition.
The company promises free replacements through partners and continued revocation and status services until issued certificates expire or are replaced. It also says digital signatures, eSign, enterprise PKI and identity services continue. This is an announced plan, not a completed migration. The statement does not set one shutdown date for every customer.
For your website, ask for written confirmation of the replacement trust hierarchy, the installation owner and the transition schedule. Do not wait for ordinary expiry if a certificate will lose trust sooner.
Actual scope: eight intermediates do not mean 30,000 victims
| Figure | What it means | What it does not establish |
|---|---|---|
| 8 intermediate certificates | 6 TLS and 2 code-signing certificates with recoverable keys. | Not eight websites; a CA can authorize other certificates. |
| About 30,000 certificates | eMudhra's initial October 20 estimate of certificates requiring migration from the G3 hierarchy. | Not a count of attacks, people or compromised servers. |
| Approximately 97% through ACME | The proportion reported by eMudhra within that migration estimate. | No guarantee that an ACME client renews before distrust takes effect. |
| October 27, morning PDT | Chrome's expected general rollout for removing the G3 root from its store. | Not a date until which every client will accept it: others have already removed it. |
Sources: the incident record, eMudhra's October 20 estimate and Google's timeline. These estimates are not presented as a final audited inventory.
The October 21 CERT-In notice distinguishes the international service from India's domestic digital-signature services and states that the cited reports do not establish confirmed malicious exploitation. This does not eliminate the risk to unpatched clients. Nor does it mean P-384 itself is broken: the issue was key generation with insufficient randomness.
What happened to eMudhra's certificates?
The public incident record identifies eight intermediate certificate authority certificates: six for TLS and two for code signing. Mozilla independently recovered their private keys. Its investigation found all eight P-384 private values were below 256.
An intermediate CA can sign other certificates within the authority granted by a root. The scope therefore extends beyond one website's key. Keep three elements separate when investigating: the trusted root, intermediate certificates and the certificate presented by each service.
Why a key with the value 4 cannot protect a CA
Scott Helme's independent analysis describes a key with the value 4: one digit, not four digits. The reference to roughly 116 digits illustrates the decimal scale of the P-384 value space, not a formatting rule that guarantees security. The essential requirement is unpredictable generation with sufficient entropy; padding a small number with zeros does not make it secure.
Documented recovery of weak keys does not establish theft through an intrusion. In Bugzilla, eMudhra preliminarily attributes the issue to key generation and selection; investigation remains open.
Firefox's response and the actual risk
According to Mozilla, an attacker intercepting a connection could use fraudulent certificates to impersonate websites if the client still trusted the chain. Firefox completed OneCRL blocking on October 17 at 22:59 UTC, 2 hours and 53 minutes after receiving the report, for standard configurations without a restart. On October 20 it released Firefox 158.0.1 and ESR 115.43.1/153.5.1 to cover configurations that had not received OneCRL.
October 21 update: Mozilla released Firefox for Android 158.0.2 at 08:29 UTC to fix cases where the bundled OneCRL blocklist did not take effect immediately on startup. Android users should install this additional update.
This does not establish that all HTTPS was broken or every website attacked. Technical capability, client trust and evidence of exploitation are separate questions.
eMudhra states that its roots and other intermediate certificates are unaffected and none of the eight issued end-entity certificates. These are company statements, not independent proof that every system is protected. Distrusting a root does not establish that its private key was compromised.
Chrome: emSign ECC Root CA–G3 distrust on October 27
Google announced removal of emSign ECC Root CA–G3 from the Chrome Root Store, with general rollout expected on the morning of October 27, 2026, Pacific Daylight Time (PDT). Services relying on that root should obtain and install a certificate under another trusted hierarchy beforehand. Google also says clients enforcing Certificate Transparency were protected against this attack path. Do not extend that protection to every client.
What to check in your hosting, VPS or application
The following is our suggested workflow for organizing the work. Adapt it to your services and each component's official support channel.
1. Separate incoming and outgoing connections
Make two inventories: domains and APIs you serve, and HTTPS services your applications contact. Include webhooks, scheduled jobs, integrations, monitoring agents and test environments. Assign each item an owner and an acceptance test.
If you use a CDN or proxy, record the public-facing and origin-facing connections separately. Checking the website's homepage does not replace testing the paths used by your application.
2. Identify the actual chain and the store validating it
From an administration workstation with OpenSSL, inspect a domain you own or are authorized to check. Replace the example hostname:
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error < /dev/null
Run your project on a VPS with clear responsibilities
Compare resources for your website or API and define who maintains certificates, applications and the operating system. Choosing a VPS does not replace maintenance.
OpenSSL's documentation explains that -showcerts displays certificates sent by the server, not an already verified chain. The root may be absent. -verify_hostname checks the hostname; -verify_return_error stops on validation errors. The result depends on the local trust store. Success does not establish universal protection or the absence of compromise.
To inspect a public certificate saved as PEM, without opening or sharing a private key:
openssl x509 -in certificate.pem -noout -subject -issuer -serial -dates -fingerprint -sha256
This displays identity, issuer, validity and fingerprint. It does not measure private-key strength or certify that the entire chain is trusted. Compare identification with your provider's advisory. openssl x509 reference.
3. Update the components actually performing TLS
Cloudflare recommends updating systems, runtimes and CA bundles, including container images. Applications can use a different trust store from browsers. Do not fix new errors by disabling TLS verification. Its statement that it observed no active exploitation applies to its own services, not the entire Internet.
As a deployment control, record which package or image changed, when it became active and which instance was checked. Test integrations from the runtime actually serving production. A resolved ticket should contain evidence of the change, not merely a planned installation.
4. Replace the chain where needed and verify the result
- Confirm scope: domain, TLS termination point, issuer and dependency on the distrusted root.
- Coordinate reissuance: request an alternative trusted hierarchy from your provider. Confirm which certificate and complete chain to deploy.
- Prepare the change: preserve the configuration needed to restore service without reintroducing unsafe trust. Assign an owner and execution window.
- Verify afterwards: check the served domain and chain in relevant browsers and API clients. Test automated renewal as well.
Python, Node.js and containers: browser updates do not update them
The Python announcement recommends certifi 2026.10.19, pip 26.2.2 and uv 0.13.4 or later, alongside reviewing sigstore, Conda and Pixi where used. Python 3.15.1, 3.14.9 and 3.13.17 include patched pip, but existing virtual environments need separate attention. Read our eMudhra Python guide: checking and updating pip, certifi and uv.
Node.js also released fixes on October 21. Our Node.js 22.23.4, 24.22.1 and 26.12.1 guide explains the changes and eMudhra key blocking, including the limitation of resumed TLS sessions. Updating host packages does not replace runtimes or CA stores bundled inside an old image.
Frequently asked questions
Should I replace every certificate?
Do not decide from a headline alone. Identify the chains you use and follow the instructions that apply to them. Ask your provider for a domain-specific answer.
Will changing passwords or switching hosts fix this?
Those are separate decisions from managing TLS trust. Prioritize the affected chains and clients. If there are signs of an intrusion, also initiate the appropriate incident-response process.
What should I ask my provider?
Request written confirmation of scope, ownership of each change, a replacement chain where needed and successful testing. Avoid a generic “everything updated” answer that does not identify services.
Plan your project's maintenance
When evaluating infrastructure, explore TERAMONT VPS plans and agree who maintains certificates, applications and the operating system. If you are getting started, read what a VPS is and the responsibilities involved. Buying resources does not replace a security review.