使用 Visual Studio 和 LibZ 容器对程序集进行签名

Question

我有一个在 Visual Studio 中创建的相对简单的 WPF 应用程序。因为该应用程序有一些依赖的 DLL（从 Nuget 中提取的包），所以我也一直在使用一个名为 LibZ Container 的帮助应用程序，它与 ILMerge 类似，但它适用于 WPF 应用程序。 （换句话说，它将 EXE 和所有 DLL 组合到一个 EXE 文件中。）

当我将我的 EXE 文件上传到网络并随后下载它时，我会收到一个警告——在我使用的任何浏览器中——该文件可能不安全。例如，这是 Chrome 的警告：

我的假设是我看到这个警告是因为文件没有签名。所以，我从 Comodo 购买了一个代码签名证书。跳过了很多不同的环节，最终获得了正确 PFX 格式的证书，但我最终做到了，并且能够在 Visual Studio 中为我的项目的构建属性的“签署程序集”部分使用它.

这似乎工作正常，这意味着项目成功构建并使用 PFX 文件进行签名。 但是，如果我通过运行 signtool verify /pa MyCoolApplication.exe 检查文件，signtool 实用程序会报告该文件未签名。这甚至在我尝试使用 LibZ 容器合并 DLL 之前。

当我使用 LibZ Container 进行合并时，我使用这个命令：

libz injection-dll --assembly MyCoolApplication.exe --include *.dll --move

和往常一样，这行得通；但是，如果我使用 signtool 检查内容，它仍然会报告该文件未签名。然后我尝试通过运行以下命令来使用 LibZ 的内置签名机制：

libz 符号 --include MyCoolApplication.exe --key key.pfx --password abc123

但是，我从中得到的控制台输出结果是：

Assembly '.\MyCoolApplication.exe' 已签名，因此无需重新签名

如果有人好奇，我可以发布该命令的完整输出。但同样，signtool.exe 报告该文件未签名。这里有两种我不知道的不同类型的签名吗？

如何使用我的代码签名证书对该可执行文件进行签名，以便浏览器警告消失？我错过了什么？

Answer 1

经过一些研究，这个问题（错误消息，而不是signtool 问题）似乎很常见。不幸的是，似乎也没有一种普遍接受的方法来解决它。大量文章和论坛帖子比比皆是推荐补救措施，但经验支持非常薄弱。话虽如此，这些补救措施似乎得到了最合理的支持：

1. Request a review of your site/link from Google
2. Add a logo to your executable
3. Make sure your headers are in order
4. 将您的网站添加到Google Webmasters
5. 让更多人下载文件，或者自己从多台机器下载多次。

几位发帖人建议您尝试签署您的文件，但似乎没有太多经验验证，或 Google 提及。

Answer 2

所以，当我发布这个问题时，我没有意识到，简单地勾选“签署程序集”实际上只是第一步，但还需要明确调用 signtool.exe 来签署可执行文件。

我发现 a number of guides online 都解释说是这种情况。多亏了这些指南，我意识到我需要运行这些命令：

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe" sign /f key.pfx /p abc123 /t http://timestamp.comodoca.com /v "MyCoolApplication.exe"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe" sign /f key.pfx /p abc123 /fd sha256 /tr http://timestamp.comodoca.com/?td=sha256 /td sha256 /v "MyCoolApplication.exe"

我还发现了一个名为 StrongNameSigner 的第三方库在自动为我正在使用的未签名第三方库提供强名称方面的作用。