eMudhra Certificate Compromise: Is Your Site Affected?

Last updated: 24 October 2026 (added eMudhra’s exit from the SSL/TLS business, the exact Chrome removal date and Red Hat’s bulletin). Based on statements from browser vendors, eMudhra, CERT-In and the researchers who reported the issue (sources at the end). We will update this page as root stores change.

On 17 October 2026, researchers showed that eight intermediate certificate authority (CA) certificates of eMudhra, an Indian certificate authority, had private keys so weak that anyone could calculate them; one key was simply the number 4. Browsers blocked the certificates within days, and Mozilla removed one eMudhra root from Firefox. On 22 October, eMudhra announced that it is leaving the global SSL/TLS certificate business. This guide explains, in plain terms, who is actually affected and what website owners, developers and everyday users in India should do.

The short version

You are…	Are you affected?	What to do
A website owner with an eMudhra / emSign SSL certificate	Possibly, if your certificate chains to emSign ECC Root CA – G3	Check your chain now and replace the certificate before browsers stop trusting the root
A developer running Go, Python, Node.js or curl apps	Your app may still trust the bad certificates if it uses its own certificate store	Update Go, certifi, ca-certificates and other trust bundles
A normal internet user	Low risk	Update your browser and operating system
A user of DSC tokens or Aadhaar eSign	No	Nothing; MeitY says these services are separate and unaffected

What happened

Websites prove their identity with TLS (SSL) certificates. Those certificates are signed by intermediate CAs, which in turn are signed by a root CA that browsers trust. If someone obtains an intermediate CA’s private key, they could issue a valid-looking certificate for any website.

eMudhra says a script error during its key ceremony on 30 April 2025 produced a second, extremely weak set of keys, and those weak keys were used for eight intermediates: six for TLS (DV, OV and EV, in G3B and G3C versions) and two for code signing. Their private keys were whole numbers below 256, so they could be recovered almost instantly. Some had Sectigo cross-signed copies with the same keys. According to eMudhra, only one of the eight was in production use and none had issued website certificates, and Google found no rogue certificates in Certificate Transparency logs. There is no known misuse so far.

Timeline

17 October: issue reported to the browser root programs; Chrome (CRLSet) and Firefox (OneCRL) block the intermediates the same day.
19 October: Android blocks them through Google Play services; issue disclosed to other trust stores.
20 October: Microsoft blocks them; Mozilla removes emSign ECC Root CA – G3 from its root store (NSS); Firefox 158.0.1 released.
21 October: CERT-In publishes advisory CIAD-2026-0050; Go releases 1.27.3 and 1.26.10 (CVE-2026-111943); MeitY forms a team to investigate. eMudhra confirms it has stopped issuing certificates from every intermediate under the G3 ECC root.
By 22 October: Apple products block the certificates.
22 October: eMudhra’s board decides to withdraw from the global SSL/TLS certificate business. Its DSC, eSign and other products continue.
23 October: Red Hat updates its bulletin RHSB-2026-012. Updated ca-certificates packages for RHEL are still pending.
Tuesday 27 October: Chrome’s removal of emSign ECC Root CA – G3 reaches all devices that use the Chrome Root Store. Google gives the date in US Pacific time, so in India expect it from the night of 27 October. Chrome Beta and Canary get it earlier.

eMudhra is leaving the SSL/TLS business: what it means

On 22 October, eMudhra said its board had decided to “voluntarily withdraw” from the global SSL/TLS certificate business. The company says SSL/TLS is only about 1% of its revenue. This is what we know so far:

Only website (TLS) certificates are affected. eMudhra says DSC, eSign, emSigner, CertiNext and its other products carry on unchanged.
Free replacements: eMudhra says it will contact affected customers and replace their certificates free of cost through partner CAs. It has not yet named the partners or given a timeline.
Existing certificates: revocation and status services will keep running until every certificate it issued has expired or been replaced. Its older G1 RSA roots keep serving customers until the transition ends.
The G1 root is safe for now: Mozilla said on 20 October that it is not removing emSign Root CA – G1 “at this time”. Chrome says it is still reviewing eMudhra’s remaining roots.
Scale: Chrome counted about 30,800 unexpired certificates under the G3 ECC root, almost all issued through InCommon, a US research and education partner.

Our advice: if any of your certificates come from eMudhra or emSign, move them to another CA now, even if they chain to the G1 root and still work. The issuer is leaving the market, so a second forced move is likely, and it is easier to do it once on your own schedule.

Website owners: check your certificate chain

The biggest practical risk for site owners is not the eight broken intermediates but the root removal. Once a browser removes emSign ECC Root CA – G3, every website certificate that chains to it shows a security error in that browser, even if the certificate itself is fine. Run this from any Linux or macOS terminal (replace the domain):

# Show the subject (s:) and issuer (i:) of every certificate the server sends
openssl s_client -connect your-domain.com:443 -servername your-domain.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|i:"

If any issuer line mentions emSign or eMudhra, your certificate comes from eMudhra. You can also click the padlock in your browser, open the certificate details and look at the certificate hierarchy. If it chains to emSign ECC Root CA – G3:

Get a replacement certificate from a different CA hierarchy now. eMudhra says it will replace affected certificates free of cost through partner CAs; free Let’s Encrypt certificates are also an option for most websites.
Install the new certificate and its full chain, then test in Chrome, Firefox and on a phone.
Check other places that use certificates: APIs, mail servers, load balancers, VPN gateways and mobile apps that pin certificates.

If you also signed software with an eMudhra code-signing certificate from the affected G3 intermediates, contact eMudhra about re-signing.

Developers and server admins: update trust stores

Browsers are already protected, but many programs use their own list of trusted certificates and do not check revocation. They may keep trusting the broken intermediates until updated:

# Debian / Ubuntu: system trust store
sudo apt update && sudo apt install --only-upgrade ca-certificates

# RHEL / AlmaLinux / Rocky / Amazon Linux
sudo dnf upgrade ca-certificates

# Python apps that use certifi (requests, httpx, pip)
pip install --upgrade certifi

# Go: check the version, then rebuild with Go 1.27.3 or 1.26.10 or later
go version

Also update Node.js, Electron apps and any appliance or container image that bundles its own CA list as patches become available. On macOS, the built-in /usr/bin/curl may keep trusting the certificates because it does not check revocation; use an updated curl or keep macOS updated. To test a client, the researchers published test sites such as https://dv-g3b-emudhra.we-have-a-problem.com/: a correctly patched client should refuse to connect.

RHEL users: Red Hat says RHEL 6 to 10, UBI containers, CoreOS and OpenShift all ship the affected roots in ca-certificates. As of 23 October its fixed packages were not yet listed. Check your version with rpm -q ca-certificates, follow bulletin RHSB-2026-012, apply the update as soon as it appears, and rebuild container images afterwards.

Everyday users

Update your browser, phone and computer. Chrome, Firefox, Edge, Safari and Android already block the broken certificates, so the risk for normal browsing is low. If a website you use suddenly shows a certificate error after 27 October, it is probably still using an eMudhra certificate that chains to the removed root; contact the site owner rather than clicking through the warning.

Is my DSC or Aadhaar eSign affected?

No. Officials from MeitY and eMudhra say Digital Signature Certificates (DSC) and eSign services in India are regulated by the Controller of Certifying Authorities and run on separate infrastructure. This incident concerns certain emSign TLS and code-signing certificates used by websites and software.

Lessons for every organisation

Know where your certificates come from. Keep an inventory of certificates, issuers and expiry dates, including on internal systems.
Be able to replace certificates quickly. Automating issuance and renewal (ACME) turns a CA incident into a routine change.
Keep trust stores updated on servers, containers and appliances, not just on desktops.

This incident was one of many in a busy week; see our “Black October” fact-check. Want us to check your websites’ certificates and TLS configuration? Run our free website safety check or see our VAPT services.