I don't think blocking rapid re-keying on the CA side is going to do much good to prevent this kind of thing. It would help with the pattern described in Ransom

I don't think blocking rapid re-keying on the CA side is going to do much good to prevent this kind of thing. It would help with the pattern described in RansomPKP, but that's not the only option available to attackers. The web server does not need direct access to the (maliciously added) private key - a separate service under the attacker's control that holds the private key and signs stuff for the web server would be sufficient (this is basically what CloudFlare does with Keyless SSL[1]). I see some potential for CAA to help prevent these attacks. Limiting issuance to a small number of CAs would help, especially if those CAs are ones you have a business relationship with and have agreed to some sort of out-of-band confirmation process for all certificate requests (I believe this is fairly common for high-risk domains). There's been some discussion about account key pinning via CAA in the ACME WG. Account keys could be kept separate from the web server (possibly even in a HSM), so this could also help mitigate this problem. That being said, none of that is going to do any good while checking CAA records is optional for CAs, not to mention that just about no one knows it even exists (even in the infosec community, as you have demonstrated). Hopefully we'll see some movement on that front in light of recent mis-issuance reports. [1]: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...