So, Heartbleed. But it's not enough just to generate new certificates, right? You actually need to get the CA to <i>revoke</i> the old one, otherwise the (possibly stolen) original private key <i>is still valid</i>?<p>Or have I lost it?
Yes. If you run something sensitive, you should also consider:<p>- Invalidating any open sessions (i.e. cookies), since those could have been stolen.<p>- Force password changes for all users (since those could have been intercepted in memory)<p>- Change internal passwords.
Anything that was in memory was potentially leaked in a way that can't be traced. Certs, SSH keys, user passwords, database passwords...<p>Oh, and if an admin logged in at any time during the window in which you were vulnerable to Heartbleed, or if any similar credential ended up in memory in any way during that period - consider yourself rooted.<p>Heartbleed is a "burn down the server, redeploy, restore database backups, expire all credentials" event, not just an "apt-get update, done" problem. And it hit over 2/3rds of HTTPS websites (ideally: anything with passwords, then some).
When you have a CA rekey a cert, they will revoke the old one. (This doesn't apply if you are using your own CA, I'm only talking about commercial ones like Globalsign, Geotrust, Comodo, etc...)