Do I have to update my snakeoil certificate after updating openssl (heartbleed)?

Solution 1:

No, you do not need to bother to update them.

It is true that now that heartbleed bug (possibly) has exposed your private key, any third party on network path in between your users and your server ("man in the middle") can see all data as is it was not encrypted.

However, for snakeoil certs, that does not differ much from regular usage case of non-compromised keys, as MITM attack on non-CA certificates is in practice equally trivial. (note that there is a tehnical difference between those two security issues, but in practice they're of the same "weight", so that does not make much difference in real world)

Since you're using snakeoil certs (instead of your own, or some other trusted CA) and so presumably ignore any warnings on such certificates, you should be aware that any data on such SSL connections is really not any more secure than plaintext connection. snakeoild certs are intended only so you technically test the connections before installing real certificate (either signed by your own CA and depending on your PKI - preferable but way more work; or putting trust in some commercial CA, and paying for the less work but lower security)

So in general heartbleed bug has two effects:

1. allowing random memory read; which is fixed the moment the apply the security update
2. making you unsure if your CA-signed SSL certs are now (security-wise) as worthless as snakeoil ones (and so have to be regenerated and reissued from trusted source). And if you were using snakeoil in the first place, that is obviously non-issue.

Solution 2:

Well, for starters You SHOULD NOT be using a snakeoil cert.

In order to properly mitigate the heartbleed attack you MUST REVOKE the potentially compromised certificates, which you generally can't do with snakeoil or other self-signed certs.

If you can't afford real Certificate Authority issued certificates (or you're working in a private environment) you should set up your own CA and publish a proper Certificate Revocation List so that you can mitigate compromises like this (as well as lost keys, etc.)
I know it's a lot more work, but it's The Right Way To Do Things.

All that said, Yes - you must replace this certificate and key if you want to ensure the security and integrity of future communications, so now is a good time to either switch to a key issued by a known Certificate Authority, or to establish your own internal CA.

Solution 3:

Assuming that you (or clients, users, etc) have ever passed, or will pass, sensitive information over SSL, yes. Passwords, anything else that you wanted encrypted because you didn't want it in plaintext. Yes.

If you truly don't care if those things are potentially in the wild as plaintext, then don't.

If you do care, don't forget to change your private key before putting on the new certificate.