Last updated: 23 October 2026. 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. 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.
- 22 October: Apple products block the certificates.
- Around 27 October: Chrome’s removal of emSign ECC Root CA – G3 is expected to reach devices (Chrome Root Store version 43).
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 has said it will move affected customers; 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 versionAlso 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.
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.
