由于交叉签名链不包含 microsoft，驱动程序安装失败
您知道为什么签名证书链中会缺少“Microsoft 代码验证根”吗？
我们最近在两个域之间移动了构建系统，并且必须重新安装证书。我们发现我们遇到了一个签名问题，微软不在链中，导致安装过程中内核驱动程序被拒绝。
我们注意到 certmgr 中有 2 个额外的证书：受信任的发布者：证书
- 3 类公共主要认证..
- Verisign 3 类代码签名...
禁用 3 类公共主要认证后，“问题”消失了我们有正确的签名链，微软位于最上面。
我不确定3 级公共主要认证是如何安装的，或者我们使用它的目的，并且正在测试以了解我们可能面临的影响。
有人遇到过这种问题吗？他们是如何解决的？有没有办法在命令行上禁用 3 类，以便我可以单独保留 certmgr 设置，从而降低风险？
感谢您的帮助
Peter
签名命令
signtool.exe sign /v /ac MSCV-VSClass3.cer /s TrustedPublisher /n "My Corp" /t http://timestamp.verisign.com/scripts/timstamp.dll mydriver.sys
签名验证 Signtool 验证 /kp /v mydriver.sys
*** Signing Certificate Chain:
*** Issued to: Class 3 Public Primary Certification Authority
*** Issued by: Class 3 Public Primary Certification Authority
*** Expires: 8/2/2028 7:59:59 PM
*** SHA1 hash: xxxxxxxxxxxxxxxxxx
Issued to: VeriSign Class 3 Code Signing 2009-2 CA
Issued by: Class 3 Public Primary Certification Authority
Expires: 5/20/2019 7:59:59 PM
SHA1 hash: xxxxxxxxxxxxxxxxxx
Issued to: My Corp
Issued by: VeriSign Class 3 Code Signing 2009-2 CA
Expires: 9/10/2013 8:59:59 PM
SHA1 hash: xxxxxxxxxxxxxxxxxx
Do you know why "Microsoft Code Verification Root" would be missing from a signing certificate chain?
We recently moved a build system between two domains and had to re-install certs. We found that we had a signing problem where Microsoft wasn't in the chain causing kernel driver rejection during install.
We noticed that we had 2 additional certs in certmgr : Trusted Publisher : Certificates
- Class 3 Public Primary Certification..
- Verisign Class 3 Code Signing...
After disabling Class 3 Public Primary Certification the "problem" went away and we have the proper signing chain with Microsoft on top.
I'm not sure how Class 3 Public Primary Certification was installed or what we using it and am testing to see what impacts we might face.
Has anyone run into this kind of problem and how did they approach it? Is there a way to disable the use of the class-3 on the command line so I can leave the certmgr setting alone thereby reducing risk ?
Thanks for the help
Peter
Sign Command
signtool.exe sign /v /ac MSCV-VSClass3.cer /s TrustedPublisher /n "My Corp" /t http://timestamp.verisign.com/scripts/timstamp.dll mydriver.sys
Sign Verification
signtool verify /kp /v mydriver.sys
*** Signing Certificate Chain:
*** Issued to: Class 3 Public Primary Certification Authority
*** Issued by: Class 3 Public Primary Certification Authority
*** Expires: 8/2/2028 7:59:59 PM
*** SHA1 hash: xxxxxxxxxxxxxxxxxx
Issued to: VeriSign Class 3 Code Signing 2009-2 CA
Issued by: Class 3 Public Primary Certification Authority
Expires: 5/20/2019 7:59:59 PM
SHA1 hash: xxxxxxxxxxxxxxxxxx
Issued to: My Corp
Issued by: VeriSign Class 3 Code Signing 2009-2 CA
Expires: 9/10/2013 8:59:59 PM
SHA1 hash: xxxxxxxxxxxxxxxxxx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
理论上，我可以将与我的证书匹配的 verisign 的交叉签名证书安装到证书存储中，signtool 将自动使用它。但是，这可能会导致使用错误的证书进行交叉签名。
明确更好 在受
签署
SignTool .exe 签名 /v /s trustpublisher /ac 检索证书路径\MSCV-VSClass3.cer /n myCertName /t http://timestamp.verisign.com/scripts/timestamp.dll driver-file-to-signSignTool.exe verify /kp /v driver-file-to-check或如果您有目录文件
SignTool.exe verify /kp /v /c driver-cat-file.cat driver-sys-file.sysIn theory, I can install the cross-sign cert from verisign that matches my cert into a cert store and signtool will automatically use it. However, this can lead to the wrong cert being used to cross sign.
Being explicit is better
SignTool.exe sign /v /s trustedpublisher /ac path-to-retrieved-cert\MSCV-VSClass3.cer /n myCertName /t http://timestamp.verisign.com/scripts/timestamp.dll driver-file-to-signSignTool.exe verify /kp /v drive-file-to-checkor if you have a catalog file
SignTool.exe verify /kp /v /c driver-cat-file.cat drive-sys-file.sys我们比较了两个构建系统，并在不良系统的 certmgr 可信发布者列表中发现了额外的 3 类公共主要证书。这与我们连锁店的顶层相匹配。我们禁用了此发布，并将链的顶部恢复到了微软。
所以，我们仍然有疑问，但这似乎已经解决了我们的问题，并且没有对其他构建产生不良影响。
We compared two build systems and we found an additional Class 3 Public Primary cert in our certmgr trusted publishers list on the bad system. This matched with the top level in our chain. We disabled this publish and the top of the chain was restored to microsoft.
So, we still have questions but this appears to have resolved our problem with no ill effects to other builds.