在尝试自动编译和签署特定的基于NSIS的二进制文件时,我遇到了一些奇怪的行为。即,makensis
在wine
下运行以编译可执行文件,然后osslsigncode
用于对二进制文件进行签名。
可执行文件似乎可以很好地构建,因为它适用于Windows系统,但是签名时存在问题(缺少更好的词)。由于代码签名证书采用PKCS#12格式,因此使用的命令如建议的here:
osslsigncode sign -pkcs12 <pkcs12-file> -pass <pkcs12-password> \
-n "Your Application" -i http://www.yourwebsite.com/ \
-in yourapp.exe -out yourapp-signed.exe
我得到了成功&#34;来自osslsigncode的消息,好像签名没问题,但是当二进制文件在Windows上运行时(在这种情况下为Win 7),UAC说:
发布商:未知
奇怪的是,当我从原始.p12
文件中打开提取的证书时,为了查看它的信息,Windows之后能够识别出版商和数字签名,就好像它以某种方式变成了了解认证路径......?
任何建议都将不胜感激。
编辑1
使用的osslsigncode版本:1.5.2和1.7.1
编辑2
为了便于比较,我尝试使用SignTool
进行签名,显然它没有任何问题。所以这看起来像cert + osslsigncode
问题,但我无法确切地说出它是什么。
我还尝试osslsigncode
与另一个证书完全相同的EXE,为了使事情更有趣,它起作用了......(我注意到2个证书的认证路径不同)。
一些证书细节:
1)非工作证书
版本:V3
公钥:RSA 2048位
签名哈希算法:sha1
签名算法:sha1RSA
认证路径:USERTrust - &gt; Comodo代码签名CA 2 - &gt; NonWorkingCert
2)工作证书
版本:V3
公钥:RSA 2048位
签名哈希算法:sha1
签名算法:sha1RSA
认证路径:USERTrust - &gt; UTN-UserFirst-Object - &gt; Comodo代码签名CA 2 - &gt; WorkingCert
答案 0 :(得分:2)
这花了我几个小时的时间,但我想我现在明白了。
解决方案是将中间证书与主证书一起传递到osslsigncode
。 (H/T to Tor Project for confirming this。)
查找正确的中间CA证书。可以通过openssl x509 -text -in cert.pem
完成,然后查找“ Authority Information Access
->“ CA颁发者” URI。证书标识符(序列号等)也可以在Windows中的“数字证书”选项卡->“查看证书”->“证书路径”下找到。
(提示:并不总是信任CA的支持页面来获取要下载哪个中间证书的正确信息,从CA的网页上下载了错误的中间证书后,我浪费了很多时间。)
< / li>openssl x509 -in my_intermediate_ca.crt -inform der -outform pem -out my_intermediate_ca.pem
或类似的格式将所有证书转换为PEM格式。将完整的CA链放入一个PEM文件中,首先对代码签名证书:cat mycert.pem my_intermediate_ca.pem > certchain.pem
(如果代码签名证书不在链中的第一位,则Windows会看到由中间证书“签名”的无效签名。)
运行osslsigncode -certs certchain.pem ...
(注意:我也通过了-h sha256
和-ts http://timestamp.digicert.com
,尽管我也认为所有其他选项组合都可以使用。)