If you haven't heard of the Heartbleed Bug, it's something to take a look at immediately. It essentially means that an attacker can exploit a vulnerability in many versions of OpenSSL to be able to gain access to a server's private key. It is not a theoretical threat, it is a demonstrable and reproducible threat. See the above link for more information.

The question I think most organizations are asking themselves is the following:

Does every company now need to create new public/private keypairs and ask their CA to invalidate the original signed keypairs? 

It means much more than just new certificates (or rather, new key pairs) for every affected server. It also means:


Patching affected systems to OpenSSL 1.0.1g
Revocation of the old keypairs that were just superseded
Changing all passwords
Invalidating all session keys and cookies
Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly.
Evaluating any other information that could have been revealed, like memory addresses and security measures


Summarized from heartbleed.com (emphasis mine):


  What is leaked primary key material and how to recover?
  
  These are the crown jewels, the encryption keys themselves. Leaked
  secret keys allows the attacker to decrypt any past and future traffic
  to the protected services and to impersonate the service at will. Any
  protection given by the encryption and the signatures in the X.509
  certificates can be bypassed. Recovery from this leak requires
  patching the vulnerability, revocation of the compromised keys and
  reissuing and redistributing new keys. Even doing all this will still
  leave any traffic intercepted by the attacker in the past still
  vulnerable to decryption. All this has to be done by the owners of the
  services.
  
  What is leaked secondary key material and how to recover?
  
  These are for example the user credentials (user names and
  passwords) used in the vulnerable services. Recovery from this leaks
  requires owners of the service first to restore trust to the service
  according to steps described above. After this users can start
  changing their passwords and possible encryption keys according to the
  instructions from the owners of the services that have been
  compromised. All session keys and session cookies should be invalided
  and considered compromised.
  
  What is leaked protected content and how to recover?
  
  This is the actual content handled by the vulnerable services. It
  may be personal or financial details, private communication such as
  emails or instant messages, documents or anything seen worth
  protecting by encryption. Only owners of the services will be able to
  estimate the likelihood what has been leaked and they should notify
  their users accordingly. Most important thing is to restore trust to
  the primary and secondary key material as described above. Only this
  enables safe use of the compromised services in the future.
  
  What is leaked collateral and how to recover?
  
  Leaked collateral are other details that have been exposed to the
  attacker in the leaked memory content. These may contain technical
  details such as memory addresses and security measures such as
  canaries used to protect against overflow attacks. These have only
  contemporary value and will lose their value to the attacker when
  OpenSSL has been upgraded to a fixed version.

