由于私钥filter，使用signtool进行代码签名失败

在尝试签署由我所在的公司创build的安装程序时，我遇到了一个我一直无法解决的错误。我正在使用相同的证书已经在另一台机器（Win7）上使用相同的方式签署类似的安装程序。无论如何，在我们正在运行CruiseControl.net的Windows Server 2008上，我尝试用signtool.exe签署一个安装程序，并且失败，并显示以下错误消息：

The following certificates were considered: Issued to: <our company> Issued by: <some ca> Expires: <is valid> SHA1 hash: <...> Issued to: <...> Issued by: <...> Expires: <...> SHA1 hash: <...> After EKU filter, 1 certs were left. After expiry filter, 1 certs were left. After Subject Name filter, 1 certs were left. After Private Key filter, 0 certs were left. SignTool Error: No certificates were found that met all the given criteria.

我尝试将证书安装到不同的证书存储区，尝试不同版本的signtool.exe，并试图直接使用.cer文件，但没有任何区别。我在所有情况下都收到上面提到的错误。我尝试了下面的命令行命令

 signtool.exe sign /debug /n "MyCompany" C:\my\installer.exe signtool.exe sign /debug /f C:\path\to\my\certificate.cer C:\my\installer.exe

但是在某些情况下我离开了/ debug。有什么我做错了或失踪？

为了签署文件，您需要拥有证书的私钥，该私钥不包含在从Windows 7机器复制的* .cer文件中。要使用私钥导出证书，您可以按照此处提供的说明进行操作。

请注意，如果证书设置为允许在创建时导出私钥，则只能导出私钥（通过将-pe传递给makecert ）

我有同样的症状 ，但完全不同的原因 。正如许多开发人员所做的那样，我的系统上安装了一堆不同的工具链。我只是对他们进行调查，以显示这可以看起来如何; 滚动到这个答案的底部的完整列表。

我已经像往常一样使用certutil -importPFX cert.pfx从提升的命令提示符处将我的代码签名证书从VeriSign安装到系统证书存储区（需要使用signtool.exe /sm ）。

第一次测试看起来很有希望，但是突然之间签名开始失败。

为了调试这个问题，我首先开始使用signtool.exe sign /debug /v /a /sm ...来查看出了什么问题。输出看起来像这样（也见问题）：

 The following certificates were considered: Issued to: localhost Issued by: localhost Expires: Tue Dec 26 00:00:00 2017 SHA1 hash: <...> Issued to: <...> Issued by: Symantec Class 3 SHA256 Code Signing CA Expires: <...> SHA1 hash: <...> After EKU filter, 1 certs were left. After expiry filter, 1 certs were left. After Root Name filter, 1 certs were left. After Private Key filter, 0 certs were left. SignTool Error: No certificates were found that met all the given criteria.

我可以排除丢失的私钥，因为证书存储显示我有一个匹配的私钥 ：

证书的属性对话框

现在我记得最近有一些补丁允许Windows 7接受使用SHA256散列的证书签名。当然，尽管大多数较早的文章都会声明Windows 7根本无法处理SHA-2哈希值。

所以这已经给了我一个“这是一个涉及签字的旧版本”的方向。

我仍然决定删除证书加密钥，并使用之前显示的调用重新导入它。

然后，在调查我的系统（请参阅答案的底部）后，我发现了五个不同版本的signtool.exe 。所以我开始尝试最新的一个（6.3.9600.17298，从Windows 8.1 SDK）， 它立即工作 ：

 signtool.exe sign /debug /v /a /sm /r VeriSign /ac MSCV-VSClass3.cer /ph /t "http://timestamp.verisign.com/scripts/timstamp.dll" *.exe The following certificates were considered: Issued to: localhost Issued by: localhost Expires: Tue Dec 26 00:00:00 2017 SHA1 hash: <...> Issued to: <...> Issued by: Symantec Class 3 SHA256 Code Signing CA Expires: <...> SHA1 hash: <...> After EKU filter, 1 certs were left. After expiry filter, 1 certs were left. After Root Name filter, 1 certs were left. After Private Key filter, 1 certs were left. The following certificate was selected: Issued to: <...> Issued by: Symantec Class 3 SHA256 Code Signing CA Expires: <...> SHA1 hash: <...> Cross certificate chain (using machine store): Issued to: Microsoft Code Verification Root Issued by: Microsoft Code Verification Root Expires: Sat Nov 01 13:54:03 2025 SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3 Issued to: VeriSign Class 3 Public Primary Certification Authority - G5 Issued by: Microsoft Code Verification Root Expires: Mon Feb 22 19:35:17 2021 SHA1 hash: 57534CCC33914C41F70E2CBB2103A1DB18817D8B Issued to: Symantec Class 3 SHA256 Code Signing CA Issued by: VeriSign Class 3 Public Primary Certification Authority - G5 Expires: Sat Dec 09 23:59:59 2023 SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5 Issued to: <...> Issued by: Symantec Class 3 SHA256 Code Signing CA Expires: <...> SHA1 hash: <...> The following additional certificates will be attached: Issued to: VeriSign Class 3 Public Primary Certification Authority - G5 Issued by: Microsoft Code Verification Root Expires: Mon Feb 22 19:35:17 2021 SHA1 hash: 57534CCC33914C41F70E2CBB2103A1DB18817D8B Issued to: Symantec Class 3 SHA256 Code Signing CA Issued by: VeriSign Class 3 Public Primary Certification Authority - G5 Expires: Sat Dec 09 23:59:59 2023 SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5 Done Adding Additional Store Successfully signed: <...>.exe Number of files successfully Signed: 1 Number of warnings: 0 Number of errors: 0

跟踪进一步，我以为我发现了这个问题。但是，事实证明，我得到的错误不是我会看到与旧的signtool.exe版本。相反，旧版本会抱怨/ac ， /fd和/ph是无法识别的命令行选项。

所以我需要深入一点，事实证明，我的（替代）文件管理器是罪魁祸首。我通常使用该文件管理器和方便的键盘快捷方式在相应的文件夹中启动我的命令提示符。事实证明，它有时不会传递环境变量 – 本质上，文件管理器会“忘记”环境变量。原来，这是根本原因。命令提示符使用Win + R打开，然后cmd Enter不会公开此行为，尽管从同一个文件夹执行signtool.exe 。

我最好的猜测是，由于一个乱七八糟的PATH变量或类似的， signtool.exe结束了挑选错误的DLL。值得注意的是mssign32.dll和wintrust.dll 陪同signtool.exe在Windows SDK 8.0和8.1的相同文件夹 ，但不是任何早期版本的signtool.exe将选择“全局”系统范围的DLL，无论他们结果是。

在我的系统上，我有五个不同版本的signtool.exe 。

signtool.exe 5.2.3790.1830

甚至不理解我使用的/ac和/ph参数（也不是/fd ）。但奇怪的是，没有这两个论点的工作。

C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\signtool.exe

signtool.exe 6.0.4002.0

甚至不理解我使用的/ac和/ph参数（也不是/fd ）。但奇怪的是，没有这两个论点的工作。

C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\Bin\signtool.exe

signtool.exe 6.1.7600.16385

第一个理解/fd sha256版本。

C:\WINDDK\7600.16385.1\bin\amd64\SignTool.exe
C:\WINDDK\7600.16385.1\bin\x86\SignTool.exe
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe

signtool.exe 6.2.9200.20789

C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe

signtool.exe 6.3.9600.17298

C:\Program Files (x86)\Windows Kits\8.1\bin\arm\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool.exe

我在Win7机器上遇到了同样的问题，并尝试了好的人在这篇文章中建议的一切，但都没有运气。然后，即使我的机器只有一个帐户，并具有管理员权限，我通过“以管理员身份运行”打开命令提示符窗口，然后我安装的所有版本的signtool.exe开始工作。