Reading one [1] or another [2] related to the Comodo buzz [8][9], I was not surprised a bit. [3]
Note that even if you force a revocation check, or clear the OCSP/CRL cache, or use HSTS, or do 20 push ups, it may not really matter.
It’s about freshness.
For example, looking at VeriSign you may notice that they date as valid for about a week OCSP responses and CRLs.
This means, that if your app does not “demand” a “fresh” CRL from the CA or a “fresh” OCSP response from the OCSP responder and is willing to accept for example a 5 days old OCSP response, everything is (almost) pretty useless.
OCSP nonces were once used with Opera, but as far as I know most browsers currently do not use them. [3]
OCSP stapling may help an attacker in certain cases.
The culprit Comodo CA has a somewhat smaller validity for its CRL and OCSP responses.
Speaking about Windows 7 or Windows Vista, you can view the OCSP or CRL cache with the certutil command like so(by default response caching is performed):[4][5][6][7]
- view OCSP cache:
certutil -urlcache ocsp
- view CRL cache:
certutil -urlcache crl
- view both OCSP and CRL cache:
certutil -urlcache *
And you can delete the cache like:
- delete OCSP cache:
certutil -urlcache ocsp delete
- delete CRL cache:
certutil -urlcache crl delete
- delete “all” cache:
certutil -urlcache * delete
Instead of deleting you can invalidate the memory cache like so, set a expiry date for the CRL and OCSP cache(I did not mess too much with this one, sets a registry value to a specified date and time, the ChainCacheResynchFiletime value located in the HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config registry key; the ChainCacheResynchFiletime value specifies the date and time to clear the in-memory cache): [4][5][6][7]
- immediately invalidate all items from the cache:
certutil -setreg chain\ChainCacheResyncFiletime @now
- invalidate the currently cached items in 2 day, 4 hours(sets a registry value to the current date and time plus 2 days and 4 hour), basically disables temporarily the cache until after now plus 2 days and 4 hours:
certutil -setreg chain\ChainCacheResyncFiletime @now+2:4
- identify the last time that the cache was invalidated(displays registry value):
certutil -getreg chain\ChainCacheResyncFiletime
- to delete a registry value:
certutil -delreg chain\ChainCacheResyncFiletime
Clearing the OCSP cache affects, as writing, browsers like IE and Chrome.
Also the certutil command has an option(GUI) to verify the status of a certificate:
certutil -url ‘certificatefilename’
Additionally you can check the validity of a certificate like:[10]
certutil -f –urlfetch -verify 'certificatefilename’
References
[1] Detecting Certificate Authority compromises and web browser collusion
https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
[2] Revocation doesn't work
http://www.imperialviolet.org/2011/03/18/revocation.html
[3] Random SSL/TLS 101 - OCSP/CRL in practice
http://www.carbonwind.net/blog/post/Random-SSLTLS-101-OCSPCRL-in-practice.aspx
[4] How to refresh the CRL cache on Windows Vista
http://blogs.technet.com/b/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspx
[5] How Certificate Revocation Works
http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx
[6] Online Responder Installation, Configuration, and Troubleshooting Guide
http://technet.microsoft.com/en-us/library/cc770413(WS.10).aspx
[7] Certificate Revocation and Status Checking
http://technet.microsoft.com/en-us/library/bb457027.aspx
[8] Report of incident on 15-MAR-2011
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
[9] Fraudulent SSL certificates
http://netsekure.org/2011/03/fraudulent-ssl-certificates/
[10] Basic CRL checking with certutil
http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx