我在Visual中创建了一个相对简单的WPF应用程序。由于应用程序有一些依赖的DLL(从Nuget中提取的包),我还使用了一个名为LibZ容器的助手应用程序,它与ILMerge类似,但它适用于WPF应用程序。(换句话说,它将EXE和所有DLL组合到一个EXE文件中。)
当我把我的EXE文件上传到网上,然后下载它时,我会收到一个警告--不管我在哪个浏览器--这个文件可能不安全。例如,Chrome的警告如下:


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

这似乎工作正常,这意味着项目成功构建并使用PFX文件进行签名。然而,,,如果我通过运行signtool verify /pa MyCoolApplication.exe来检查该文件,那么signtool实用程序将报告该文件是无签名的。这甚至在我尝试使用LibZ容器合并DLL之前就已经存在了。
当我使用LibZ容器进行合并时,我使用以下命令:
libz注入dll程序集MyCoolApplication.exe包括*.dll移动
和往常一样,这是可行的;但是,如果我使用signtool检查东西,它仍然会报告文件是未签名的。然后,通过运行以下命令,尝试使用LibZ的内置签名机制:
libz符号-包括MyCoolApplication.exe密钥key.pfx密码abc123
但是,我从中获得的控制台输出以这样的话结束:
程序集'.\MyCoolApplication.exe‘已经签名,因此不需要辞职
如果有人好奇的话,我可以发布命令的全部输出。但是,signtool.exe再次报告该文件未签名。这里有两种不同类型的签名,我不知道?
如何使用代码签名证书对此可执行文件进行签名,以使浏览器警告消失?我遗漏了什么?
发布于 2017-01-11 22:35:47
所以,当我发布这个问题时,我没有意识到的是,简单地勾选“签名程序集”才是真正的第一步,但是还需要显式调用signtool.exe来对可执行文件进行签名。
我发现一个数字 导游者 在线都解释说是这样的。感谢这些指南,我意识到我需要运行这些命令:
"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的第三方库在自动为我使用的未签名的第三方库指定强名称方面的有用性。
发布于 2017-01-06 19:11:20
经过一些研究,这个问题(错误信息,而不是signtool问题)似乎很常见。不幸的是,似乎没有一种普遍接受的方法来解决这个问题。大量的文章和论坛帖子充斥着对补救措施的推荐,但经验支持却非常薄弱。尽管如此,这些补救办法似乎得到了最合理的支持:
签署你的文件,你已经尝试过,是推荐的几个海报,但似乎没有太多的经验验证,或任何提及谷歌。
https://stackoverflow.com/questions/41490503
复制相似问题