首先,联想在运送 Superfish 的新 PC 时被发现,其中包括一个通用的自签名证书颁发机构,而现在戴尔被发现运送带有类似根证书的 PC。
当我获得一台新 PC 以确保没有错误的证书颁发机构或根证书时,我可以采取哪些步骤?
- 有没有可以自动检查的程序?
- 是否可以遵循任何指南以确保仅安装了标准证书颁发机构和证书?
首先,联想在运送 Superfish 的新 PC 时被发现,其中包括一个通用的自签名证书颁发机构,而现在戴尔被发现运送带有类似根证书的 PC。
当我获得一台新 PC 以确保没有错误的证书颁发机构或根证书时,我可以采取哪些步骤?
Bryan Lockwood 在 GitHub 上放了一个不错的项目:
这是他介绍它的博客文章
您可以像这样运行脚本:
复制Nov2015-WindowsRootCAList.txt到Nov2015-WindowsRootCAList.NOSPACES.txt
解决错误:手动删除Nov2015-WindowsRootCAList.NOSPACES.txt.
(否则脚本会将所有内容报告为不受信任。)
(我建议您使用您最喜欢的文本编辑器的搜索和替换功能,然后删除所有空格。)
点源脚本:
PS C:\Powershell-PKI-master> . .\Audit-TrustedRootCA.ps1 3>&1 | out-null
运行函数:
PS C:\Powershell-PKI-master> Audit-Roots -FilePath .\Nov2015-WindowsRootCAList.NOSPACES.txt -OutputPath .\
针对已知良好哈希列表的 Windows 信任存储(存储?)脚本。
这个哈希列表的来源对我来说并不完全清楚。
所以我决定用一些 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
事实证明:certutil来自 GitHub的哈希值和来自 GitHub的哈希值实际上是相同的:
$ diff --report-identical-files -- wuroots-hashes-pspkiformat.txt Nov2015-WindowsRootCAList.txt
Files wuroots-hashes-pspkiformat.txt and Nov2015-WindowsRootCAList.txt are identical
这个由德国安全研究员 Hanno Böck 发起的 Twitter 帖子将我带到了 PowerShell 项目。
上个月有一篇很棒的博客文章:
Mike 概述了生成.sst证书容器的过程,该容器仅包含从 Windows 更新中检索到的默认证书,然后使用 MMC 从中进行选择。
certutil -generateSSTFromWU rootcas.sst
invoke-item rootcas.sst
我没有试过,但我猜测,从SST文件抛出每一个CA,然后简单导入所有默认的CA应该做部分的伎俩。
注意:我不知道 Windows 如何处理“中间”商店或其他地方的自签名 CA。我认为该商店无论如何都是一个缓存并且可以被破坏,因为无论如何它都会自动重建 - 但我不确定。
编辑。我刚刚注意到 Tom Leek 去年对类似问题给出了基本相同的答案: