One bad key ceremony: what the eMudhra incident teaches about trusting certificates

Every HTTPS connection rests on a chain of trust: your browser trusts a root certificate, the root vouches for an intermediate certificate authority, and the intermediate vouches for the website. Most of the time nobody thinks about that chain. Then a link in it fails, and thousands of websites that did nothing wrong have to change their certificates in a hurry.

In October 2026 that happened to eMudhra, an Indian certificate authority trusted by every major browser. It's worth understanding, because it will happen again to some CA, and the lessons don't depend on which one.

What happened

On 17 October 2026, someone proved to the browsers' root programs that they held the private keys of eight of eMudhra's intermediate certificate authorities. They hadn't broken in anywhere. The keys were so weak that anyone could work them out from the public certificates - one of them was the number 4.

How a key can be guessed

The eight intermediates used elliptic-curve keys on the P-384 curve. An elliptic-curve private key is just a number, d, which should be chosen at random from a range about 384 bits wide - a number more than 100 digits long. The public key, published in the certificate, is that number multiplied by a fixed point on the curve:

public key = d × G

Going from d to the public key is easy; going back is meant to be impossible, because there are far too many values of d to try. But every one of these keys was smaller than 256. Recovering one meant trying d = 1, 2, 3 and so on, comparing each result with the public key - at most 255 attempts, done in well under a second. The key for the intermediate EM OV TLS CA - G3C was 4.

The cryptography itself was never at fault. By eMudhra's account, a script changed for a test during its April 2025 key ceremony created a second set of weak keys alongside the proper ones; their labels looked alike, and the weak ones were picked. Six of the intermediates were then cross-signed by Sectigo, so they were trusted through Sectigo's long-standing root as well. The keys stayed recoverable for about 17 months.

Why it mattered

Whoever holds an intermediate CA's private key can issue a certificate for any domain, and every client that trusts the chain will accept it. That's what makes these keys among the most sensitive secrets on the internet - and why the response was so fast.

Why browsers were safe, and other software maybe not

Chrome, Firefox, Safari and Edge only accept a website certificate that has been published in public Certificate Transparency logs. A certificate quietly issued with one of these keys would either be missing from the logs, and rejected, or visible to anyone watching them. None turned up, and eMudhra said the intermediates never issued a certificate to a customer.

Much other software doesn't check Certificate Transparency: command-line tools, language runtimes, mobile apps, services calling each other's APIs, devices. Whether anyone used the keys against those during the 17 months isn't known.

How the trust was withdrawn

2026
17 October	The keys are reported. Firefox blocks the intermediates through OneCRL that evening, without needing an update; Chrome blocks the six TLS intermediates.
18 October	eMudhra revokes all eight; Sectigo revokes its cross-signs over the next day.
20 October	Mozilla removes trust in emSign ECC Root CA - G3, the root above them, and Microsoft blocks the certificates. Chrome schedules the same root's removal.
By 22 October	Apple blocks the certificates. eMudhra announces it is leaving the global TLS certificate business.

Operating systems and libraries shipped updated certificate lists over the following days - Ubuntu, Debian, Alpine, Homebrew, Python's certifi, Rust's webpki-roots, Go and others.

The websites that did nothing wrong

Removing a root doesn't only shut out the bad intermediates. It ends trust in every certificate under that root - certificates issued properly to customers who did nothing wrong. eMudhra put the number at about 30,000. Each had to be replaced with a certificate from another CA before browsers dropped the root, or its site would start showing warnings.

That's the part that reaches ordinary website owners: a failure at your CA becomes a deadline for you.

The lessons

• A CA is only as strong as its weakest key ceremony. The maths was fine. A script and two similar labels undid it.
• Certificate Transparency works. It's why browsers could treat this as a near miss rather than a breach.
• Revocation doesn't reach everything. Browsers pushed blocks within hours. Anything with its own certificate list waited for an update - so keep CA bundles and runtimes current, on servers and in containers too.
• Your CA's problem can become your deadline. When a root is distrusted, every certificate under it has to go, whoever's fault it was.
• Know which CA issued each of your certificates, and be able to switch. With ACME, moving to another CA is usually a configuration change, not a project - if you've set it up before you need it.

What to keep in place

1. An inventory of every certificate you serve and who issued it - the website, and the load balancers, CDNs, mail servers and APIs behind it. For one host:

   openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null \
     | grep -E '^ *[0-9] s:|^ *i:'
   

2. A way to replace certificates quickly, ideally automated, and a second CA you could switch to.

3. Current CA bundles in everything that makes TLS connections, so distrusted certificates stop being trusted when they should.

Where Mon helps

Mon's SSL monitoring reads the certificate each of your servers actually presents, on any port, every day, and shows who issued it - so when a CA is in trouble, a glance at your list tells you which certificates are affected. When you replace one, the next daily check shows the new certificate and its issuer once the server is using it, on every host and port you watch, which is how you find the endpoint still serving the old one.

Mon also flags a certificate whose chain isn't trusted. Its checkers judge trust by their own systems' certificate lists, though, which update on their own schedule rather than any one browser's - so when a CA is distrusted, look at the issuers straight away rather than waiting for that alert.

Mon is free for up to 5 certificates. Start for free, or check a certificate now without signing up.