It's almost a shame it includes the private key and doesn't bruteforce it in-band for every request.

This looks like it's using the emSign root path, which is useful, but the AAA root path is equally useful in different cases. The AAA root path was disabled for https on root stores newer than February 2025, but has been in root stores since forever. Meanwhile the emSign root path was only included in root stores since ~2018 and got removed in October 2026.

So from the perspective of hacking old IoT devices, if your device hasn't been since 2018, the AAA path should work; if since February 2025, either path works; if since October 2026, the emSign path.

I created a proxy using the 6 compromised eMudhra CA keys (2 of the 8 are code-signing and not for TLS). I initially tried just one (the one with d=4) like in the commit, but it did not seem to work for anything. Once I added all 6 keys, I was able to intercept some.

I was mainly interested in testing which IoT devices are affected and protecting them, not trying to sniff their traffic since it's been a long day. My proxy thus just intercepted and forwarded the traffic upstream using a fresh TLS connection that does not use the compromised keys.

If I’m understanding correctly, you could sniff the communication between your Smart TV and the manufacturer using this method?

Looking forward to setting this up manually after my agent refuses to do it. Like the good ol’ days.

I thought this cert only recently gets trusted, so only newish but not too new devices would be vulnerable. Am i misunderstanding how this works?

How much of a boon is this for jailbreaking, reverse engineering, and mitm really?

This is gonna be great to sniff apps in a couple older Android phones I have around. Hope they're not pinning certificates.

Oh, nice. I was thinking of setting up a proxy for this for testing, nice to just have it working out of the box.

Someone should've coined this disaster as "QuattroFail" to give it a little panache and international mystery