First Lenovo was caught shipping Superfish with new PCs, which included a universal self-signed certificate authority, and now Dell has been caught shipping PCs with a similar root certificate.

What steps can I take when I get a new PC to make sure that there are no bad certificate authorities or root certificates?

  • Are there any programs that can automatically check this?
  • Are there any guides that can be followed to make sure there are only standard certificate authorities and certificates installed?
  • Evil CAs aren't the only risk, you can very well have a rootkit that intercepts TLS without actually being visible from the system itself. THe only way to be sure (at least for software-based attacks) is to reinstall the system from a known good image like an official Microsoft ISO. Commented Nov 24, 2015 at 8:58
  • 1
    That's often not an option if you buy a new PC - you would get an OEM recovery image/disk. To get an official Microsoft ISO, you would have to buy a new copy of Windows.
    – JonnyWizz
    Commented Nov 24, 2015 at 9:00
  • 1
  • Related question: 2014-10-22: Reset Windows trusted certificates store to its default Commented Nov 24, 2015 at 9:59
  • @AndréBorie, you also need to make sure that you do not run some software from the manufacturer later. For example Dell installs a trusted root cert when Dell System Detect is run (see e.g. here: youtube.com/watch?v=DYLYG76o55c)
    – x457812
    Commented Nov 24, 2015 at 15:49

1 Answer 1


Edit 2015-11-25

"PowerShell-PKI" project looks promising

Bryan Lockwood has put a a nice project on GitHub:

And here's his blog post that introduced it

You can run the script like so:

  1. Copy Nov2015-WindowsRootCAList.txt to Nov2015-WindowsRootCAList.NOSPACES.txt

  2. Work around a bug: Manually remove the trailing space characters in Nov2015-WindowsRootCAList.NOSPACES.txt.
    (Otherwise the script will report EVERYTHING as untrusted.)
    (I suggest you use your favorite text editor's search-and-replace-feature and just nuke all spaces.)

  3. Dot-source the script:
    PS C:\Powershell-PKI-master> . .\Audit-TrustedRootCA.ps1 3>&1 | out-null

  4. Run the function:
    PS C:\Powershell-PKI-master> Audit-Roots -FilePath .\Nov2015-WindowsRootCAList.NOSPACES.txt -OutputPath .\

The script the Windows trust store (stores?) against a list of known-good hashes.

Hashes-list is same as from certutil.

The origin of this hash-list is not entirely clear to me.

So I decided to generate the hashes myself with a bit of Cygwin-Bash-Scripting:

$ certutil.exe -generateSSTFromWU wuroots.sst
$ certutil.exe -dumpPFX wuroots.sst  | grep 'Hash' | tr -d ' ' | tr 'a-z' 'A-Z' | cut -d ':' -f2 | sed 's/$/ /' | sort > wuroots-hashes-pspkiformat.txt

And it turns out: the hashes from certutil and hashes from GitHub are in fact identical:

$ diff --report-identical-files -- wuroots-hashes-pspkiformat.txt Nov2015-WindowsRootCAList.txt
Files wuroots-hashes-pspkiformat.txt and Nov2015-WindowsRootCAList.txt are identical

Related Twitter Thread

This Twitter thread started by German security researcher Hanno Böck led me to the PowerShell project.

Maybe CertUtil and MMC to reset?

There was a great blog article last month:

Mike outlines a procedure to generate an .sst certificate container with just the default certificates retrieved from Windows Update and then uses MMC to pick and choose from them.

certutil -generateSSTFromWU rootcas.sst
invoke-item rootcas.sst

I haven't tried this, but I'm guessing that throwing out every CA and then simple importing all the default CAs from the SST file should do part of the trick.

Note: I don't know how Windows handles self-signed-CAs in the "Intermediate" store or elsewhere. I think that store is a cache anyway and can be nuked because it will be automatically rebuilt anyway -- but I'm not certain.

Prior art

EDIT. I just noticed that Tom Leek gave essentially the same answer to a similar question last year:


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .