By contrast, illegitimate issuance by a CA that browsers trust is a threat to everyone's security. Furthermore, the parties directly harmed—the owners of the domains of the illegitimate certificates and their users—typically have no relationship at all with the offending CA, and consequently no direct recourse against it. That's why browser vendors—the only parties that CAs truly have to answer to—have to get involved in such cases.
"Assessing the compatibility risk with both Edge and Safari is difficult, because neither Microsoft nor Apple communicate publicly about their changes in trust prior to enacting them."
Why or why not would you want to withhold this kind of information?
I think that it's even possible to issue another certificate with different CA using old private key. I'm not sure if all CA communicate with each other about revoked keys.
But the point here is that there was no compromise. None at all, the author simply forged the whole thing and submitted it as part of a legitimate bundle for added plausibility in case there was a human in the loop (which there shouldn't be, and anyway that part could be trivially forged too, just register a bunch of domains over time, get certs for them, then leak the actual legitimate private keys on purpose). So having a primary/backup/backup backup/backup backup backup/backup^n is all useless in this scenario because only the public component was necessary to make a fake sufficient to fool Symantec's incompetent systems.
It's not just recommended, it's required. HPKP can certainly lock you out of your own site if done wrong but there are safeguards against that. A shockingly high number of sites that try to use HPKP don't actually do anything at all because every browser out there ignores their HPKP headers because they're malformed in some way.
I don't see why the impact on a site using HPKP would be different than for any other site. In both cases the site would have to install a new cert.
The only difference with the HPKP site is that they'd need to make sure their new cert uses the same key as the old one. (Or they could use a backup key/cert, which I'd expect them to have anyway if they're using HPKP.)
If I got that type of error/reissue email, I would assume it was something fairly normal going on, when in reality I really, really need to know that the private key had been leaked.
Edit: Jul 9 snapshot from https://archive.fo/Zdmck didn't include those instructions, so they only added that recently.
In fact, a lot of the really good hacking stories are. The recent .IO takeover for example.
But make sure than neither p nor q is 1.
This makes me wonder how easy it would be to social engineer getting Symantec to revoke a third party's cert, even if you don't have the private key, just by having a talented person on a phone with faked outgoing caller ID via SIP trunk. See: Mitnick's Art of Deception book for examples.
There are multiple ways to properly check this. However the point is: Symantec didn't do it and the vast majority of the guides you find on the Internet about this are wrong.
I cry a little every time sometimes uses /tmp this way.
This is insecure.
chmod a+w /tmp/pubkey.pem
No sticky bit, no restrictive umask, also no protected_hardlinks/protected_symlinks is going to save you.
While we're on the subject of the openssl tool and file permissions, I've been disappointed... On my system, this command creates key.pem word-readable: "openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes" I've been meaning to set my umask to fix issues like this, as I have rare need to let another user account access my files. On the other hand, there aren't supposed to be any other users on my systems, and it's more likely my browser will get pwned and have access to my self-readable private keys anyway.