eMudhra Certificate Compromise: Is Your Website Affected and What to Do (2026)

Last updated: 28 October 2026 (Chrome’s root removal date has passed, eMudhra now offers free Sectigo replacement certificates, Red Hat’s fixed ca-certificates versions and AWS’s deadlines added). 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, Mozilla removed one eMudhra root from Firefox, and Chrome’s removal of the same root was due to reach all devices on 27 October. 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.

Affected by this? Emergency exposure check, ₹2,999, 48 hours. Send us up to 5 hosts, sites or product versions. Within 48 hours you get a written verdict for each one, what to patch first and how to verify the fix. Book the check or ask a question first.

The short version

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.
• 22 October: eMudhra starts offering Sectigo-issued certificates to its customers as a free alternative.
• 22–23 October: Red Hat releases fixed ca-certificates packages for RHEL 8, 9 and 10 (bulletin RHSB-2026-012).
• 24 October: AWS publishes bulletin 2026-150-AWS with its own trust-store changes and deadlines (see below).
• Tuesday 27 October: the date Google set for removing emSign ECC Root CA – G3 from the Chrome Root Store on all devices (morning US Pacific time, night of 27 October in India; Chrome Beta and Canary had it earlier). As of 28 October, Google had not posted a separate confirmation, so treat the root as no longer trusted in an up-to-date Chrome. Sites still on it show NET::ERR_CERT_AUTHORITY_INVALID.

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 from Sectigo: on 22 October eMudhra said it is making Sectigo-issued certificates available to all its customers at no cost, both for the affected G3 certificates and its other TLS customers. Request one through your CertiNext account, or write to support@emudhra.com (support@certinext.io for US customers). InCommon, the largest user of the G3 root, is still deciding how its members will get new certificates.
• 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: eMudhra says its G1 roots remain active and fully supported. Mozilla said on 20 October that it is not removing emSign Root CA – G1 “at this time”, and Chrome says it is still reviewing eMudhra’s remaining roots. No final decision had been announced by 28 October.
• 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:

1. Get a replacement certificate from a different CA hierarchy now. eMudhra offers free Sectigo certificates (see above); free Let’s Encrypt certificates are also an option for most websites. If your domain has CAA DNS records, add the new CA first, or it cannot issue.
2. Install the new certificate and its full chain, then test in Chrome, Firefox and on a phone.
3. 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. Fixed packages are out for current releases: check with rpm -q ca-certificates and make sure you have at least the version below, then rebuild container images. RHEL 6 and 7 have no fixed package listed yet; Red Hat’s bulletin RHSB-2026-012 describes a manual blocklist workaround.

AWS users: AWS bulletin 2026-150-AWS removes the affected roots from its own trust stores. If an Application Load Balancer uses OIDC or JWT login and the identity provider’s certificate chains to an eMudhra root, replace that certificate by 28 October. Also check CloudFront origin certificates, rebuild Lambda container images, run sudo yum update ca-certificates on Amazon Linux, and update boto3/botocore to 1.43.117 or later.

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 “Your connection is not private” error since 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.

Related guides

• ISO 27001 Cryptography: Control 8.24 Use of Cryptography Explained
• How to Set Up an SSL Certificate for Nginx: Let’s Encrypt and OpenSSL
• ISO 27001 Communications Security: Network Controls and Information Transfer (2022)
• Internet and Web Technology Basics: Internet vs Web, URLs and DNS

Sources

• The Hacker News: eight eMudhra CA keys compromised
• BleepingComputer: Mozilla, Google, Apple block compromised eMudhra certificates
• Mozilla Security Blog: protecting Firefox users
• Researchers’ incident site with test endpoints
• Go security release announcement
• Google: protecting Chrome and Android users (root removal on 27 October)
• The Hacker News: eMudhra to exit the global SSL/TLS business
• Red Hat bulletin RHSB-2026-012: eMudhra certificate compromise
• eMudhra: statement on the certificate security incident (updates and Sectigo option)
• AWS security bulletin 2026-150-AWS
• InCommon: certificate service update