eMudhra's Bad Keys, and Why I Still Won't Decrypt Your Traffic

On Saturday a researcher told Apple, Google, Microsoft, Mozilla and eMudhra that eight of eMudhra’s intermediate certificate authorities had private keys anyone could recover in under a second. By Tuesday Mozilla had gone public and shipped an NSS update pulling eMudhra’s root out entirely. Most of the coverage since has landed on “the browsers handled it,” and that covers the browsers. It leaves out most of the other TLS clients on your network, probably including the box your security team keeps asking to turn decryption on.

What happened

eMudhra created eight intermediate CAs in April 2025. Six issue TLS certificates (DV, OV and EV, two generations each, G3B and G3C) and two issue code signing certificates. In May 2025, Sectigo’s AAA Certificate Services root cross-signed all eight. Remember that cross-sign. It keeps biting after the browsers are done.

Each of those intermediates uses a P-384 elliptic curve key. A P-384 private key is supposed to be a random 384-bit number, roughly 2^384 possibilities. These keys were… a single byte. That’s 256 possibilities, so recovering one takes at most 255 guesses, and Scott Helme’s writeup recovered all eight on a laptop in under a second. Anyone holding those keys could issue a certificate for any domain, or sign any binary, and it would chain up to a trusted root.

How it happened

eMudhra’s preliminary explanation, posted to Mozilla’s bug tracker, is a flaw in the key ceremony code. It generated a second, weaker set of keys on the HSM, and because “the key labels were similar,” the certificate signing requests got built from the wrong ones. eMudhra also admits to “human errors in multiple steps of the process” and says it hasn’t confirmed the exact root cause yet. Key ceremonies are about the most audited procedure in the CA business. A label mixup, if that’s what it was, got through anyway, and eight intermediates sat in the trust chain for a year and a half before anyone looked at the public keys closely enough to notice.

What it means for IT security

The browsers, to their credit, moved fast. Google got the report at 18:05 UTC on Saturday and had a CRLSet block out by 19:45. Mozilla had the intermediates blocked through OneCRL by 22:59 the same night. Chrome, Firefox and Safari all require Certificate Transparency, and Chrome says no TLS certificate chaining to the six TLS intermediates was ever logged to CT before its block went out, so a forged certificate wouldn’t have been trusted by default in Chrome anyway.

Now think about everything on your network that speaks TLS and isn’t a browser. curl, Python, Node, Go, Java, git and every package manager trust a CA bundle sitting on disk. By default they don’t check revocation and they don’t check CT. Scott forged a certificate for api.stripe.com with one of the recovered keys, and curl, Python and Node all accepted it on Linux and macOS.

On a network team, that list is your automation… Ansible runs, Python scripts pulling from controller APIs, zero touch provisioning fetching images and configs, and CI pipelines holding cloud credentials and signing keys. Then there’s the gear itself. An appliance ships with a CA bundle baked into its firmware, and that bundle changes when you upgrade, which for some boxes in some closets means never. We already watched what a certificate baked into network gear can do when Viptela’s expired in 2023 and took SD-WAN edges down with it.

Pulling eMudhra’s root doesn’t fix any of this either, because of that cross-sign. The eight intermediates also chain to Sectigo’s AAA Certificate Services. Chrome and Mozilla have already dropped that root, and Sectigo has revoked the cross-signs, but AAA Certificate Services spent two decades in trust stores, and a frozen firmware bundle still carries it. Revocation only helps a client that checks, and we’ve established most of them don’t.

So the cleanup list looks like this.

• Update OS CA bundles on every Linux box, and update certifi, Node and anything else that ships its own bundle.
• Rebuild container images once the base images pick up the new bundles.
• Check your appliance vendors for advisories, and ask the ones that haven’t posted one.
• Check the trusted CA list on any firewall or proxy doing TLS decryption.

The box in the middle

A decrypting firewall or proxy is a TLS client. It opens its own connection to the server, validates the server’s certificate against the firewall’s own CA store, then mints a new certificate for that site, signed by your enterprise CA, and hands that one to the user’s browser. Every managed endpoint trusts your enterprise CA, because that’s how decryption works.

CRLSet, OneCRL and CT enforcement, the protections that covered everyone during this incident, all run in the browser, against the certificate the browser sees. With decryption on, the browser sees the firewall’s certificate. Chrome doesn’t enforce CT on certificates that chain to a locally installed root, so the firewall’s minted certificate sails through. The only check left on the real certificate is whatever the firewall does, with whatever CA bundle the firewall’s vendor last shipped.

If that bundle still trusts the Sectigo cross-sign, a forged certificate goes in one side of the firewall and comes out the other signed by your own company, where the browser’s CRLSet and CT checks can’t catch it.

Why I still won’t decrypt

I don’t decrypt TLS at the edge, and I don’t recommend it to anyone who asks. I wrote about this back in 2024 after yet another vendor meeting, and my answer then was to inspect at the endpoint and leave the trust chain alone. Nothing since has changed my mind, and this week handed me a better example than I had then.

In March 2017, US-CERT (now CISA) published TA17-075A, “HTTPS Interception Weakens TLS Security”, built on a study by Durumeric et al. that found 11 of 12 middleboxes tested made the connections passing through them less secure. The core of the alert is one line… “the client systems have no way of independently validating the HTTPS connection.” By 2019 the message from the same agencies had become a how-to, the NSA’s Managing Risk from Transport Layer Security Inspection, which CISA relayed. The government went from warning people about decryption to teaching them how to do it, and of course that’s the shift vendors quote back at you, along with the “break and inspect” entry in TIC 3.0’s capability catalog.

The rest of the paper trail is more cautious than the decks let on. OMB’s M-22-09, the federal zero trust memo, tells agencies to “balance the depth of their network monitoring against the risks of weak or compromised network inspection devices,” and expects inspection to “become less practical and less valuable over time.” A decrypting firewall still trusting the Sectigo cross-sign this week fits “weak or compromised network inspection device” pretty well.

The vendor pitch is always visibility, and I’ll admit it gets harder to argue with every year. Cloudflare’s 2025 Year in Review put HTTPS at more than 95% of the requests it saw. An IPS that can’t read TLS is effectively blind, and my argument against decrypting gets a little weaker every time that number climbs. I still think decrypting is a bad trade. The price is that every TLS trust decision in the company runs through one box, checked against one vendor’s CA bundle, updated on that vendor’s release schedule. Chrome’s block landed an hour and forty minutes after the report. How long did your firewall vendor take? Does anybody on your team know where to look to find out?

My answer is the same one I gave in 2024… look at the traffic on the endpoint. EDR sees the traffic on the machine that made the request, before it’s encrypted and after it’s decrypted, and the browser on that machine keeps its CRLSet, OneCRL and CT checks against the real certificate. Nothing in the middle re-signs anything, and the trust decision stays with the browser that already got this one right.

Patch your bundles this week. And the next time decryption comes up in a vendor meeting, ask how fast their trust store dropped eMudhra.