It has been shown that Heartbleed can be used to leak SSL private keys (if the attackers are lucky). So now many experts are recommending that you revoke and re-issue SSL certificates for your web server. Can the certificate revocation mechanism cope?
Just cracked @CloudFlare ’s challenge: https://t.co/8ZPSxyKF4D . I wonder when they’ll update the page.
— Fedor Indutny (@indutny) April 11, 2014
Quick background on Certificate Revocation Lists (CRLs)
If we look at the SSL certificate for the Nexor web site (by going to https://www.nexor.com, and clicking the padlock symbol), we can see the certificate as: 
I have highlighted a field called the CRL distribution point. If we now go to the URL specified (http://crl2.alphassl.com/gs/gsalphag2.crl), we can see the CRL revocation list. On the tab “Revocation List”, we can see a list of the serial numbers of all the certificates that have been revoked…
Today, this list contains about 1,200 items.
So What…
In theory (sadly, theory and practice deviate) every time you visit https://www.nexor.com your browser should check the certificate. Part of this process is to check that the certificate the web site is producing is not on the CRL, if it is, it is bad, and you should not trust the site. Your browser should download this CRL and check the list; if they don’t you cannot trust the site.
Spot the problem caused by Heartbleed – this list will get very large, instead of thousands we could see (according to some estimates) 6.5 million certificates needing to be revoked. This will slow your browser down considerably, to the extent it will probably break.
OCSP
This problem has been forseen, and the Online Certificate Status Protocol (OCSP) was invented to deal with the situation. In short, you call out to a server that has downloaded the CRL for you, and ask it to search the list for the certificate you are interested in. Dealing with large lists is seen as a must-have capability of OCSP servers, but it is not clear how many do.
Even this can take time, so a mechanism called OCSP stapling was invented, in which the web site ‘staples’ the OCSP response to the SSL query. FireFox can do OCSP stapling, but like all browsers is dependent upon the web server cooperating.
Google uses its own mechanism in Chrome.
Status check.
What is not clear is how widely OCSP and the variations are actually implemented. This tweet from the guys that discovered SSL private keys can be leaked by Heartbleed, suggest not as widely as it needs to be…
Now we finally see that OCSP is a future and CRL is just impossible to maintain, though no one has expected it to be used on that scale
— Fedor Indutny (@indutny) April 12, 2014
Heartbleed is certainly going to cause many headaches long into the future while these issues are sorted out – in the interim its hard to know what can be trusted…
See Also
Once Upon a Camayoc 
There may be 6.5m live SSL certs, but take the maths a bit further. Only about 30% of these are actually at risk (lots of Linux/Apache distros are unaffected, IIS is unaffected, load balancing SSL terminators are unaffected etc.) Those certs are issued by thousands of CAs, not just one. When checking a cert, you only read the crl for the issuing CA, which brings the number of entries in your CRL down to a more manageable few thousand. OCSP would obviously be better, but I don’t think this is quite as likely to overload the infrastructure as it might appear at first sight.
The thing that amazes me is how some major ISPs seem to have not used HSMs to protect the private SSL keys. Those who invested in such hardware protection will have no need to replace certs.
LikeLike