Heartbleed means rotating the key, not just the certificate

The OpenSSL bug published on 7 April lets a remote client read 64KB of the server process’s memory per request, repeatedly, leaving nothing in any log. Upgrading the package stops the leak. It does nothing about the two years in which the private key, session material and whatever else was resident could have been read off any vulnerable host.

# 1. patch, then confirm the binary on disk is the patched one
apt-get update && apt-get install --only-upgrade openssl libssl1.0.0
openssl version -a | head -2

# 2. every process that linked the old library is STILL running with it
lsof -n | grep 'libssl.*DEL'
checkrestart                      # debian-goodies
service nginx restart; service postfix restart

# 3. a new key, not just a new certificate
openssl genrsa -out /etc/ssl/private/example.com.2014.key 2048
openssl req -new -sha256 
  -key /etc/ssl/private/example.com.2014.key 
  -out /etc/ssl/example.com.2014.csr

Step two is the one that gets skipped. Upgrading the library does not touch the copy already mapped into a running nginx or postfix, so a box can be fully patched and still leaking until every process that linked it has been restarted; lsof listing deleted libssl mappings is how you find them, and a reboot is the version that needs no list. The certificate work is the expensive half. Reissuing is normally free from the CA, but revoking the old certificate is what limits the damage from a key somebody already has — and browser revocation checking is unreliable enough that it should be treated as a formality rather than a fix. Rotate everything else that was resident in that memory too: session secrets, API credentials, and the database password sitting in a long-lived connection.