I was just looking at my certificate store and saw a bunch of root CAs that look kind of suspicious; specifically numerous ones that:

  • have ALL CAPS text
  • use foreign languages/text
  • have extremely long expiration dates
  • include every certificate purpose possible

I strongly believe that some of these are bad (the Intermediate CA list looks clean, only the Root CA list looks bad.) However, there are enough certificates in the store to make investigating each one a real chore. (I see in the Event Log that Windows has not auto-updated the trusted third-party root list for over two weeks.)

Does anyone know of a way to verify certificates and weed out the bad ones (or at least to manually trigger an update)?

  • 3
    In the mean-time, I (1) downloaded the latest CA update, (2) manually removed every item from every part of the certificate store, (3) stopped cryptsvc, deleted catroot2, started cryptsvc, and (4) applied the update. Hopefully a less scorched-earth method can be found so that legitimate certificates don't get wiped out like this since they are not included in the update from Mirosoft. – Synetech Mar 14 '12 at 19:07
  • Think you got yourself an answer. – Belmin Fernandez Mar 14 '12 at 21:46
  • @BeamingMel-Bin, it’s more of a work-around than a solution. I blasted the whole thing including valid certs that Microsoft doesn’t include. I’m looking more for a program or website that lets you scan or submit certs. – Synetech Mar 15 '12 at 1:00
  • Hm, perhaps I'm misunderstanding what you meant by "bad ones" since it's all based on trust. Do you mean that you believe some are compromised (i.e., the private key is out in the wild)? Otherwise, seems like cleaning out your current store and adding ones you trust or trust by association (Microsoft trusted and your own) is your only option. – Belmin Fernandez Mar 15 '12 at 1:37
  • I mean that it looks like a bunch of bad ones have somehow been snuck in there, ones that allow sites and files to be trusted when they shouldn’t, hence the long expiration dates and full-privileges. – Synetech Mar 15 '12 at 2:49

You can have a look at Debian's list of certificates, and weed out the ones that are not there; then apply the latest Microsoft CA update and add the ones you have installed manually. But as Debian says:

Please note that certificate authorities whose certificates are included in this package are not in any way audited for trustworthiness and RFC 3647 compliance, and that full responsibility to assess them belongs to the local system administrator.

  • I had already tried deleting all of the certs and installing the latest update, but it didn’t help. – Synetech Aug 28 '12 at 15:30

You can quickly find out which ones weren't included originally by running sigcheck sigcheck.exe -tv *, which compares the root CA in your local computer against a list it downloads from Microsoft. Then it outputs the difference. Those certs which didn't come from Microsoft must have been introduced by yourself or a piece of software (i.e. antivirus for ssl inspection). In my case there was only one I didn't recognize and immediately disabled it.

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.