3

I have on my linux machine a set of root CA certs. I'd like to make sure none of the CA certs are compromised or bogus.

Any suggestions on how to do this?

  • 1
    I don't fully understand your question. Do you want to know if nobody with root access has changed any of the CA installed by the distribution and also did not add new certificates? Or do you want to check that the CA itself was not compromised, i.e. did not issue certificates it should not have? – Steffen Ullrich Jan 14 '17 at 6:49
  • 1
    Can you define 'compromised or bogus'? – schroeder Jan 14 '17 at 9:42
2

Usually known certificate authorities publish their root certificates on their websites.

For eg:

Ideally you'll check the certs you've got against equivalent fingerprints published on the respective websites.

On a linux machine, certs are stored at /etc/ssl/certs. The following command gives the fingerprint of a Thawte Primary Root CA G2 cert:

openssl x509 -in thawte_Primary_Root_CA_-_G2.pem -sha1 -fingerprint -noout

The fingerprint produced by the certs above can be looked up on the Thawte website. Similarly all root certs can be verified manually.

enter image description here


Caveat

The method above works for well known CAs like Verisign, Thawte. However there is no certain way to find out if the website of a lesser known root cert is legitimate. An attacker can somehow insert their root cert in your bundle and also host a website with the fingerprint of that cert. While not foolproof, general google search for each cert serial numbers + fingerprint pair should give enough pointers to vet most of the certs.

Also, comparing your certs with a good reference bundle, eg. one that comes with a fresh install of firefox, can be a good way to verify the certs. Obviously, the premise here is that you trust the firefox maintainers to make sure their build doesn't have a fake certificate. https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Finally, who do you trust

Suppose you find a certificate which has no presence on google/internet. Sometimes, companies install their internal root CA certs in all employee PCs/laptops. This is on purpose to allow intranet sites to be signed by internal CAs (and avoid paying verisign for certs) as well as to MITM the connections of users (yes this is not uncommon). In such a case, it boils down to what entity do you consider as trusted and what entity is malicious. One needs to use their own judgement in such situations.

  • Very good answer, but I was hoping for something a bit more automagic. I'll create a web service for this. – Blaze Jan 14 '17 at 23:54
0

I think you'd pretty much have to do a byte comparison to known good ones (assuming they are popular CA certs).

Other mechanisms are in place to help with this also:

Subject Key Identifier (SKI). A certificate extension included in CA certificates that contains a hash of the CA certificate's public key. This hash is placed in the Authority Key Identifier (AKI) extension of all issued certificates to facilitate chain building.

Certificate Chaining. Certificate chaining is defined as the trust validation of an x.509 certificate as it is compared to a trust anchor such as a root certificate.

But you didn't give a lot of information regarding how they were generated or by whom.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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