Well, even if there's no update for your shit, it's still possible to go into the certificate store your browser/OS/whatever uses and delete the compromised certificates.

Not much you can do about everyone else not updating their shit though.

I think their analogy is still good. Just add "...and your door opens onto Times Square."

That doesn't quite get the full scope, but it does imply the danger pretty well. Plus, if you add in "...Times Square of robots, and the robots are all thieves, and your most expensive possession is visibly sitting right inside, and..." it starts to get pretty unwieldy.

Yeah. The burden is high, though, and it's outside even most tech-savvy admins' scope of knowledge.

I mean, I could not tell you off the top of my head how many certificate stores exist on my system and what uses each of them. Is curl safe? Is dnf safe? apt-get? zypper? pip? npm? homebrew? flatpak? Do any of my umpteen Flatpak apps have vulnerable library versions baked in? Do Electron apps bundle their own certificate stores? What about that has its own built-in autoupdater (less of a problem on Linux than Mac or Windows, but still)?

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100

5 is objectively more secure than 4, unless 4 was perfectly random, of course.

Well ..... this has taken me down am SSL cryptographic rabbit hole.

We live in a simulation https://xkcd.com/221/

Google is wrong. There is no security benefit to using an SSL certificate signer in your jurisdiction because a hacked or malicious certificate authority in another jurisdiction can man-in-the-middle you or your customers just as effectively.

Certificate authorities do not decrypt data or even transfer it on behalf of customers.

By "export" I think they mean export off of the hardware security module (HSM). Not export geographically.

I'm not so sure. Because shortly after the above quote they answered this to the next question:

Is there any reason which may explain why the A and A-1 ECDSA keys appear to be unaffected by similar issues?

The A and A-1 series were created in Entrust HSMs and were meant for deployment only in India.

And previously in Comment 10 they said about the bad keys

These ICAs were generated from the same key ceremony on Apr 30, 2025. The G3B and G3C ICAs were created for European and US operations respectively but they were not put into production except #2 in the list below but no end entity certificates were issued from these. The Code Signing issuers were not put into production also did not issue any certificates.

That's why I think somehow the intended place of use made a difference in their process. But it could be you're right and they still mean HSM export, because the keys need to go to the region of use, and aren't transported physically in the HSM.

TL;DR Because a Certificate Authority used 4 as a private key in an intermediate certificate.

It's about compliance, not security.