Corrupted (SSL) keystore / spotting bogus SSL certificates

Question

Disclaimer: I am new to SSL, find it a little confusing, and need an answer somewhat quickly.

I was told that there was a danger that my "keystore" might be corrupted, so I am trying to examine it and make sense of it. I'm using Arch Linux.

I see a lot of fun stuff in /etc/ssl/certs (and I suppose question #1 is, "is this what the 'keystore' is?"), but that list became much more sensible when I passed it all through readlink -f and removed duplicates. It looks like all my certificates are from /usr/share/ca-certificates/. The bulk of them are in the mozilla/ subdirectory, but there are other subdirectories like:

brazil.gov.br/
cacert.org/
debconf.org/
gouv.fr/
signet.pl/
spi-inc.org/

My main problem is that I don't know how to spot a suspicious certificate. Simply going to these sites seems counter-intuitive (i.e. they may have the same malware that potentially corrupted my keystore in the first place).

ca-certificates is a package installed by my package manager; could I just purge it and then reinstall? Is that safe to do?

UPDATE:

The issue that prompted this investigation was an unrecognized VeriSign certificate. Specifically, I was given a signature with a certificate which I did not (but presumably should) have and trust.

I found this page on VeriSign's site that lists a whole bunch of certificates: http://www.verisign.com/support/roots.html ...and so I started to check the fingerprints of the certificates I have installed against those on the site.

for cert in /etc/ssl/certs/Veri[Ss]ign*; do
    printf "%s: " $cert
    openssl x509 -noout -in $cert -fingerprint
done

The result: One doesn't match. Sounds like an important one, too: "VeriSign Class 1 Public Primary CA".

Complications: My package manager tells me that my existing certificates checksum okay. Furthermore, the fingerprint on the certificate I'm supposed to have matches neither the one I have nor the one listed on VeriSign's site.

Answer 1

Certificates issued to end-entities (e.g. web server) by a CA are usually issued via an intermediate (aka chain) CA. There are several reasons for this. It was very common when CAs first starting issuing certificates this way for server operators to fail to install the intermedia CA thus visiting users who do not have a cached (or installed) copy of the chain cert in a situation where they have both the root cert and the EE cert but no way to connect them. This is much less common today but may be the issue you are facing - is this from visiting a public server - if so I'll take a look for you. You can always take a look at the issuerName of the EE cert you can't verify and see if you can find a matching 'intermediate CA" cert on VeriSign's site.. if so you should be able to verify the EE with the intermediate and the intermediate with the root. If you're going about this manually I suggest you do cert validation too - OCSP is supported by VeriSign on all their CAs... most (all?) premium CAs over this form of real time/ near real time validation... otherwise next best would be CRLs.