Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

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?


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: ...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

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.

share|improve this question

migrated from Jul 27 '11 at 19:27

This question came from our site for professional and enthusiast programmers.

up vote 0 down vote accepted

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.

share|improve this answer
It turns out that it was, in fact, and intermediate certificate I was expected to have. – koschei Aug 22 '11 at 19:59

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.