One of the private keys that was supposed to protect a trusted certificate authority turned out to be the number 4.
Not a long random number with hundreds of digits. Just 4. And it wasn’t the only one: eight intermediate certificates from eMudhra, one of India’s largest certificate authorities (it sells under the emSign brand), had keys so small that anyone could recover them in under a second.
If you run a website, an API, or anything that talks HTTPS, this is worth five minutes of your time. Firefox has already stopped trusting the root certificate behind those keys, and Chrome follows on 27 October 2026. Sites that still use that chain will start showing security warnings to visitors.
I went through the incident reports and built a small free tool so you can check your site in a few seconds: emsign-check.automationvault.net. Here’s what happened, in plain words.
What happened, in plain words
Every HTTPS certificate is vouched for by a chain: a root certificate that your browser trusts, one or more intermediate certificates signed by that root, and finally your site’s own certificate. The private keys of the root and intermediates are supposed to be huge random numbers, guarded in hardware vaults. If someone gets one of those keys, they can sign a certificate for any domain, and browsers would accept it.
Where the problem sits: the distrusted root and the revoked intermediates sit above your site’s certificate.
On 30 April 2025, eMudhra ran a key ceremony and generated 24 intermediate keys. According to eMudhra’s own account on Mozilla’s bug tracker, a faulty script produced a second set of weak keys alongside the strong ones. The two sets had similar labels, and staff used the weak keys to create eight of the certificates.
Those eight P-384 keys were all integers smaller than 256. Researchers listed them publicly: 4, 56, 66, 115, 155, 156, 230 and 237. Testing every possibility takes a laptop less than a second.
Six of the eight were for website (TLS) certificates and two for code signing. They sat in browser trust stores for about 17 months before a researcher reported them on 17 October 2026.
The good news: no misuse has been reported. Google said no website certificates chaining to the six TLS intermediates had been logged in Certificate Transparency before the block, so forged certificates from them wouldn’t have worked in Chrome. Because the keys can’t be made secret again, though, browsers are removing trust in the root that signed them.
Timeline
The browsers moved fast: the weak intermediates were blocked within hours of the report.
| Date | What happened |
|---|---|
| 27 Oct 2026 | Chrome drops emSign ECC Root CA – G3 (Chrome Root Store v43) |
| 20 Oct 2026 | Mozilla ships Firefox 158.0.1 and NSS 3.131.1, removing emSign ECC Root CA – G3. Microsoft platforms block the intermediates |
| 19 Oct 2026 | Sectigo revokes its cross-signs; Apple devices block the intermediates |
| 18 Oct 2026 | eMudhra revokes all eight certificates |
| 17 Oct 2026 | Researcher reports the problem to Apple, Google, Microsoft, Mozilla and eMudhra. Chrome blocks the six TLS intermediates via CRLSet; Firefox blocks all eight via OneCRL |
| 30 Apr 2025 | Weak keys generated during eMudhra’s key ceremony |
Am I affected?
Probably not, but it takes five seconds to be sure. You only need to act if your certificate chains to emSign ECC Root CA – G3. Certificates from other CAs, and eMudhra certificates on its RSA chain, aren’t affected by this removal.
eMudhra estimates about 30,000 certificates need to be replaced. eMudhra’s customers span banking, government, telecom and manufacturing, so if you build for any of those, it’s worth checking.
The quickest way: enter your domain at emsign-check.automationvault.net. It connects to your site, reads the full certificate chain, and gives you a clear verdict:
- Affected: your chain uses the distrusted root or one of the revoked intermediates. Fix it before 27 October.
- eMudhra, not affected: your certificate is from eMudhra, but on a chain that’s still trusted.
- Not affected: no eMudhra certificate in the chain.
Example result for a test site on the distrusted chain. The checker also recovers the weak intermediate key, which is the number 4.
For code-signing or internal certificates that aren’t on a public website, use the “Paste a certificate” tab instead.
If you’d rather check by hand, run this and look for “emSign ECC Root CA – G3” in the output:
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null 2>/dev/null | grep -E "s:|i:"How to fix it
If you’re affected, the fix is usually quick, especially if your certificates renew automatically. eMudhra said about 97% of the affected certificates were issued through ACME, the protocol behind tools like certbot, acme.sh, Caddy and Kubernetes cert-manager.
- Pick where to reissue. Either eMudhra’s RSA chain, which eMudhra says is the migration path, or another publicly trusted CA.
- Point your ACME client at the new directory URL and force a renewal. With certbot, that’s
certbot certonly --server <ACME_DIRECTORY_URL> -d example.com --force-renewal. - Install the full new chain. Make sure the old emSign G3 intermediate isn’t left in your chain file.
- Update trust stores on your servers and containers. Browsers update themselves; your servers don’t. Update
ca-certificates(Debian/Ubuntu), NSS to 3.131.1 or later, Rustwebpki-rootsto 1.0.10 or later, and rebuild container images. - Re-check your domain on the checker.
The full fix guide has commands for certbot, acme.sh, Caddy, cert-manager and manually issued certificates.
Why I built the checker
When I read the incident reports, the facts were clear but the answer to the obvious question wasn’t: is my site on that chain? You can work it out with openssl, but most site owners won’t, and the deadline is days away. So I built a simple page that answers it.
What emsign-check.automationvault.net does:
- Reads your live certificate chain over a normal HTTPS connection and matches it against the distrusted root and the serial numbers of the eight revoked intermediates, taken from Mozilla’s incident report.
- Tests every key in the chain for weaknesses right in your browser. It looks for the exact flaw behind this incident (an elliptic-curve key that’s a small number), plus common RSA problems: small factors, primes that are too close together, and short keys.
- Flags expiry, so you also see if your certificate is about to lapse.
- Never sees anything secret. A certificate only holds a public key, and the paste box refuses private keys.
It’s free, needs no sign-up, and runs on plain PHP. If you find a result that looks wrong, I’d like to hear about it.
Lessons for anyone automating certificates
This blog is about automation, and this incident is a good case study of automation going both wrong and right.
A script caused it. By eMudhra’s account, a script in a high-stakes ceremony quietly created a second set of keys, and nothing checked them before use. A simple sanity check on the generated keys (is this number suspiciously small?) would have caught it in milliseconds. If your pipeline creates anything security-critical, add an assertion that validates the output, not just the exit code.
Automation is also what makes the fix cheap. The 97% of affected certificates issued through ACME can be replaced by changing one URL and forcing a renewal. The other 3%, issued by hand, need CSRs, emails and manual installs. If you still renew any certificate manually, this is your nudge to automate it.
Trust stores need updating too. Browsers patched themselves within hours. Servers, containers and scripts that make outbound HTTPS calls use their own trust stores, which only change when you update them. Put ca-certificates updates and base-image rebuilds on a schedule.
Monitor what you serve. A daily job that checks your own certificate chains for expiry, issuer changes and distrusted roots costs almost nothing and turns a surprise into an email.
FAQ
Is eMudhra still a trusted certificate authority? Only the emSign ECC Root CA – G3 root is being removed. eMudhra’s other roots, including its RSA chain, are still trusted, though Google says it is evaluating eMudhra’s remaining CA certificate.
Were any websites actually attacked? No misuse has been reported. Because the keys existed for about 17 months, nobody can fully rule out that someone found them earlier.
What happens if I do nothing? If your certificate chains to the removed root, Firefox users already see an error, and Chrome users will from 27 October 2026.
Do I need to buy a new certificate? Usually not. If you use ACME, you change the directory URL and renew. If your certificate was issued manually, contact eMudhra about reissuance on its RSA chain, or switch providers.
Check your site now
It takes five seconds: emsign-check.automationvault.net. If it says you’re affected, the fix guide walks you through the rest. Share it with anyone who runs a site on an eMudhra certificate; the deadline is close.
This post is independent and not affiliated with eMudhra, Mozilla, Google, Apple or Microsoft. Facts are taken from the public sources below.
Sources
- Mozilla Bugzilla 2083449: eMudhra private key compromise (incident report)
- Help Net Security: eMudhra security blunder left trusted CA signing keys exposed
- BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates
- Scott Helme: Eight Bits of Trust
- The Next Web: Eight eMudhra certificate keys were so weak that one was the number 4
- Rescana: non-browser clients need updates
Leave a Reply