使用 osslsigncode 进行代码签名 - 发行商未知

Question

在尝试自动编译和签署特定的基于 NSIS 的二进制文件时，我遇到了一些奇怪的行为。即，makensis运行 来wine编译可执行文件，然后osslsigncode使用 来对二进制文件进行签名。

可执行文件似乎构建得很好，因为它可以在 Windows 系统上运行，但是签名存在问题（缺乏更好的词）。由于代码签名证书采用 PKCS#12 格式，因此使用的命令如下所示：

osslsigncode sign -pkcs12 <pkcs12-file> -pass <pkcs12-password> \ -n "Your Application" -i http://www.yourwebsite.com/ \ -in yourapp.exe -out yourapp-signed.exe

我从 osslsigncode 收到“成功”消息，就好像签名顺利一样，但是当二进制文件在 Windows 上运行时（本例中为 Win 7），UAC 表示：

出版商：未知

奇怪的是，当我打开从原始.p12文件中提取的证书并查看其信息时，Windows 随后能够识别发布者和数字签名，就好像它以某种方式意识到了证书路径......？

任何意见，将不胜感激。

使用的编辑1
osslsigncode版本：1.5.2和1.7.1

编辑2
为了进行比较，我尝试使用 进行签名SignTool，显然它的工作没有任何问题。所以这看起来像证书+osslsigncode问题，但我不知道它到底是什么。

我还尝试osslsigncode使用另一个证书使用完全相同的 EXE，并且让事情变得更有趣，它起作用了......（我注意到这两个证书的认证路径不同）。

一些证书详细信息：

1)非工作证书
版本：V3
公钥：RSA 2048 位
签名哈希算法：sha1
签名算法：sha1RSA
认证路径：USERTrust -> Comodo Code Signing CA 2 -> NonWorkingCert

2)工作证书
版本：V3
公钥：RSA 2048 位
签名哈希算法：sha1
签名算法：sha1RSA
认证路径：USERTrust -> UTN-UserFirst-Object -> Comodo Code Signing CA 2 ->workingCert

Answer 1

这让我困惑了好几个小时，但我想我现在明白了。

• Windows 有其内部可信证书数据库。其中包括根证书（由 Windows 安装和更新）以及在不同时间看到的其他中间 CA 证书（由根证书或其他受信任的证书签名）。
• 当 Windows/UAC 在启动时检查可执行文件签名时，它会在本地数据库中查找受信任的证书，该证书已对嵌入在可执行文件签名中的证书的根进行了签名。
• 如果 Windows 找不到受信任的签名证书（可能是因为嵌入式证书是使用中间证书而不是根证书进行签名的，并且中间证书不在本地数据库中），则会导致未知发布者。
• 如果您查看可执行文件属性的“数字签名”选项卡，Windows 会更进一步，尝试自动下载并安装其本地证书之一信任的任何有效中间证书。一旦将此中间证书添加到 Windows 的本地证书存储中，可执行文件启动时的签名检查也将开始通过（即显示正确的发布者）。（这个 MSDN 答案解释了逻辑，尽管他们描述的根本原因 - 根证书尚未更新 - 是不同的。）

解决方案是将中间证书osslsigncode与主证书一起传递。（H/T to Tor Project 确认这一点。）

• 找到正确的中间 CA 证书。可以通过以下方式完成openssl x509 -text -in cert.pem，然后查找“权威信息访问 -> “CA 颁发者”URI。证书标识符（序列号等）也可以在 Windows 中的“数字证书”选项卡 -> “查看证书” -> “认证路径”。

  （提示：不要总是相信 CA 的支持页面提供了要下载哪个中间证书的正确信息，在从 CA 的网页下载了错误的中间证书后，我浪费了很多时间。）

• 如有必要，将所有证书转换为 PEM 格式openssl x509 -in my_intermediate_ca.crt -inform der -outform pem -out my_intermediate_ca.pem或类似格式。

• 将完整的 CA 链放入一个 PEM 文件中，首先是代码签名证书：cat mycert.pem my_intermediate_ca.pem > certchain.pem

  （如果代码签名证书不是链中的第一个，Windows 会看到由中间证书“签名”的无效签名。）

• 跑步osslsigncode -certs certchain.pem ...

  （注：我也通过了-h sha256&-ts http://timestamp.digicert.com尽管我认为一切都可以与其他选项组合一起使用。）