eMudhra's Weak CA Keys: Is Your HTTPS Certificate Affected?

What Went Wrong

Every HTTPS certificate is signed by a certificate authority (CA). Browsers trust a short list of root CAs, and those roots sign intermediate certificates that do the daily signing. The private key behind an intermediate is the master key: whoever has it can sign a certificate for any website, and browsers will show the padlock.

A key of this type (P-384) should be a random number about 384 bits long. Mozilla's incident bug says the eight affected keys all used integers less than 256. The Register reports that security researcher Scott Helme found one key was the number 4, with others at 56 and 115, and other researchers found 66, 155, 156, 230 and 237. That is like a bank vault whose combination is 4.

Nobody had to break in. The keys could be worked out from the public certificates. eMudhra's statement of 21 October says a flaw in its key generation ceremony of 30 April 2025 caused a wrap/unwrap step to produce a second set of weak keys next to the strong ones. It also says it is still working to establish the root cause.

Timeline

According to Help Net Security, Chrome and Firefox blocked the certificates on the day of the report. Mozilla's post says its fix reached Firefox users without an update or restart.

Is Your Website Affected?

The Mozilla bug says six of the eight intermediates were for TLS (website) certificates, trusted by Chrome, Mozilla, Microsoft and Apple, and two were for code signing, trusted by Microsoft. Mozilla also distrusted the root above them, emSign ECC Root CA - G3.

On the same bug, a Chrome comment based on public Certificate Transparency logs counts about 30,800 unexpired certificates that chain to that root, most issued by InCommon subordinate CAs. eMudhra says on the bug that about 30,000 certificates need to move, about 97% of them through ACME, the protocol that renews certificates automatically. eMudhra's incident page says the root distrust affects one customer ecosystem in the United States, and that most of its TLS certificates are not affected.

Find out who issued your certificate in one command:

openssl s_client -connect yoursite.com:443 -servername yoursite.com -showcerts < /dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"

Each s: line is a certificate in your chain and each i: line is who signed it. If you see eMudhra or emSign, read on. If no line mentions either, your chain does not use eMudhra's certificates.

For the other certificate checks worth doing, such as expiry and incomplete chains, see our SSL certificate guide.

What to Do If You Use eMudhra Certificates

1. Plan to move to another CA. eMudhra is leaving the global SSL/TLS business. Its exit announcement says revocation and certificate status services keep running until every issued certificate has expired or been replaced, and that its G1 RSA roots keep serving customers until the transition is complete. It says it will contact affected customers to replace certificates free of cost through partners.
2. Ask for a replacement now if you want one. eMudhra's incident page offers Sectigo certificates as an option. CertiNext users can ask through their CertiNext account, other customers through support@emudhra.com, and US customers through support@certinext.io.
3. Automate renewal. With ACME, changing CA is a configuration change, not a manual project. eMudhra's own estimate is that about 97% of the certificates it must move can go through ACME.

The Part Browsers Cannot Fix: Your Servers and Apps

Browsers fixed this for their users within days. Other software is slower. Help Net Security reports that apps, servers and devices that do not receive revocation updates may still trust these certificates, and that Helme recommends administrators update the certificate lists their systems rely on. Mozilla removed the root in NSS 3.131.1 to protect other software that uses its trust store.

The worst setting to have in your code is one that turns certificate checks off. If it was added to get past a TLS error during development and then shipped, none of the fixes above reach that code.

// BAD: accepts any certificate, including a forged one
const agent = new https.Agent({ rejectUnauthorized: false });

// BAD: the same thing for the whole Node process
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

// GOOD: Node checks certificates by default. Leave it on, and fix the real cause of the error.
const res = await fetch('https://api.example.com/data');

Then update the trusted list your servers use once your operating system ships the change. On Debian or Ubuntu that list is the ca-certificates package. Rebuild Docker images too, because each image carries its own copy of the list.

sudo apt update && sudo apt install --only-upgrade ca-certificates

Node.js apps need one more step. The Node.js docs say Node uses its own bundled copy of Mozilla's list, a snapshot fixed when that Node version was released, so updating the operating system's list does not change it. On our machine, Node 22.17.0 still listed emSign ECC Root CA - G3 and Node 24.22.1 did not. Check the Node version you deploy:

node -e "const {X509Certificate}=require('crypto');console.log(require('tls').rootCertificates.map(p=>new X509Certificate(p).subject).filter(s=>s.includes('emSign ECC Root CA - G3')).length ? 'still trusts emSign ECC Root CA - G3' : 'G3 not bundled')"

If it prints "still trusts", move to a newer Node release whose bundled list no longer has that root.

Tools like VibeDoctor's Vibe Check (vibedoctor.io) show who issued your site's certificate and flag a certificate that the scanner's trusted list does not accept, next to expiry and HTTPS checks. Free to sign up.

FAQ