

Many sites reusing Heartbleed-compromised private keys - eliot_sykes
http://www.zdnet.com/many-sites-reusing-heartbleed-compromised-private-keys-7000029282/

======
abritishguy
You should not be responsible for website security if you don't understand the
absolute basics of SSL certificates.

It would be helpful if the CA (or reseller) confirmed (dispay a warning) that
you really want to reissue with the same private key and explain the
implications of doing so.

When reissuing a certificate the default behaviour should be to revoke the old
one after some specified time has elapsed - that is what reissuing is for and
what distinguishes it from simply buying a new certificate.

------
mobiplayer
This.

The problem is that many people in the industry doesn't really understand the
basics. How come is there a leak of your certificate, if that's the public key
you're showing to every single client that connects to your SSL enabled site?

I've even seen sysads advising on forums about reissuing certs after
Heartbleed, but no word about the keys.

~~~
higherpurpose
Maybe they should just be advised to use PFS/ECDHE instead (which should be
done anyway), and it would solve this problem by itself.

~~~
sdevlin
That would not solve the problem of active man-in-the-middle attacks.

------
pronoiac
Ugh. I think it would be better if revocation covered the public key instead
of the serial number. (I'll ignore CRL bandwidth costs and the questionable
usefulness of revocations.)

~~~
aastaneh
YUP! I covered that exact subject
([http://aminastaneh.net/2014-04-23/misconceptions-about-
mitig...](http://aminastaneh.net/2014-04-23/misconceptions-about-mitigating-
heartbleed.html)), but it didn't catch on in HN.

------
nodata
i.e. they re-used the same CSR without realising that the CSR references the
old compromised key.

------
unreal37
The odds of this being a real issue that will affect anyone are in the tiny
fractions of a percent range.

