We put lots of trust in SSL and often it's miss-configured or the libraries we use don't check all that we'd expect.
Many python libraries fail open in the case of SSL errors and revocation lists aren't even installed in most Linux distributions by default and don't tell me this is because of OCSP, that's virtually never implemented outside of web browsers.
I started to question the diligence that was being performed by package maintainers who we trust with all our secrets - those who provide the installed CA Certificates that we can check the validity of certificates against.
I wrote a simple script that walks through a directory filled with certificates, parses them for CRL information, downloads it and looks to see if it's expired. The code is a little ropy but was written for a specific purpose.
I was surprised to find 6 different root CA's with expired CRLs. This means that if one of their subordinate issuing CA's has been compromised and revoked, I'd never know - in turn any of those CA's could continue to sign bad certificates that my system would honor (if it checked revocation in the first place).
This script could easily be modified to check websites certificates or similar but for now it serves my purpose.
Here's a link to the script:
and here's the output when run on a stock Ubuntu 11.10 machine:
ubuntu@server-1345473124-az-3-region-a-geo-1:~/CRL-Scrape$ python scrape.py /etc/ssl/certs/
signet_ca2_pem.pem has a CRL pca2.crl that expired on Jan 4 11:44:13 2008 GMT
b4f0b7e7.0 has a CRL LCRacraiz.crl that expired on Dec 19 18:08:57 2011 GMT
signet_ocspklasa2_pem.pem has a CRL klasa2.crl that expired on Jan 5 10:36:58 2007 GMT
3e223c08.0 has a CRL rootca.crl that expired on Jan 5 12:32:13 2008 GMT
signet_tsa1_pem.pem has a CRL klasa1.crl that expired on Aug 3 09:38:22 2006 GMT
signet_ocspklasa3_pem.pem has a CRL klasa3.crl that expired on Jul 1 10:56:24 2006 GMT
Perhaps we should look at weather signet should really be in this bundle of trusted Certificate Authorities?