问题标签 [driver-signing]

我是 Windows 驱动程序和生产使用所需的签名程序的新手。

我最近购买了一个 GoDaddy 驱动程序签名证书，他们向我保证它应该适用于内核模式驱动程序，但是我似乎无法让它工作。

编译后，我使用以下命令使用 signtool 对 .cat 文件进行签名：

这成功完成，我使用以下命令验证证书：

上述命令的输出表明成功。你可以看到下面的输出

交叉证书部分似乎很好。我从网上发现的类似输出（从 GlobalSign 签名）中注意到，签名证书链也一直延伸到 Microsoft 代码验证根。这可能是问题吗？如果是这样，我将如何解决这个问题？

安装 .inf 很顺利，但是当我使用

我得到错误：

如果我重新启动并强制执行驱动程序签名，则上述命令可以正常工作并且驱动程序可以正常工作。我还检查了 C:\Windows\System32\DriverStore\FileRepository 中的文件在安装后也以相同的方式签名。

有谁知道为什么签名不起作用，或者我该如何解决这个问题？

先感谢您！

我是 UniversalADBDriver 的开发人员，这是一个在用户计算机上创建自签名 Android USB 驱动程序的工具。

安装程序和安装包源代码： https ://github.com/koush/UniversalAdbDriver

该工具会生成一个密钥对并将证书添加到用户的密钥库中，然后对驱动程序文件进行签名。这一直很好，直到 Windows 10，它莫名其妙地停止工作。我手动运行命令行：

在 Windows 10 上，证书被“私钥过滤器”过滤掉。不知道那是什么，上面没有任何文档。

更新

我发现通过 Windows 10 上的安装程序调用时，makecert.exe 或 X509Store.add 都无法将证书/密钥写入当前用户存储。但是，本地计算机存储中的证书放置正确。我不确定为什么会这样。所以基本上，私钥没有正确放置在存储中，因此签名失败。在命令行上手动运行相同的步骤是可行的。但是，我仍然需要弄清楚为什么私钥没有保留在商店中。

我是 Windows 徽标测试的新手。我从朋友那里听说了这个过程。我创建了一个包含一些驱动程序的应用程序。所以我需要从 Microsoft 签署我的软件的受信任安装。我通过我进行的一些测试听到了 Windows 徽标过程为我的驱动程序签名，需要将此报告发送回 Windows。所以我对设置这个过程有些怀疑。如何设置此过程？（需要多少个系统？以及我应该安装哪个操作系统进行测试）以及要求是什么？我认为有一个服务器和客户端机器（所以需要2个系统？）。如何设置这个系统？你能提供一步一步的教程吗？

我正在尝试认证 USB 设备，但我通过了所有测试，但 USB-IF 认证验证测试（设备）

我运行“USB 3 Gen X CV”并通过了 2.0 第 9 章测试。然后我将这 3 个文件移动到 c:/usblogs（我正在使用客户端计算机运行 USB-IF 测试）。

但我收到“没有通过 USB30CV CH9 测试为指定设备找到 USB2.0 日志”消息。

然后我发现这篇关于重命名文件的帖子：https ://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3227a1b0-069e-4593-9861-18d66f9dca72/usbif-test-results-log-file-格式？论坛=whck#e134fca5-e164-4d8c-8875-2dc2d66b9232

但这没有用。我也有一个以前提交的文件，可以查看并注意到它曾经生成一个 .log 文件而不是 .bak 文件。我尝试重命名但没有运气。

我尝试查找旧版本的 USB30CV 但无济于事。

我还尝试手动运行 USBIFValidation.exe 并查看失败的原因，但由于找不到“Vex.Logger.Interop”而出现异常。

使用 Windows 8.1 64

真的可以使用帮助！不知道还有什么可以尝试的。对不起，没有足够的代表来发布我的照片......

我正在尝试使用 SHA-256 证书签署 Windows 内核驱动程序。我一直在获得 MS 支持，但状态没有变化。我已经从 3 个不同 WDK（7600、8.0、8.1）的 32 位和 64 位目录中尝试了 SignTool.exe。

我的私钥位于 Luna CSP 中。我有本地证书和交叉签名证书，我可以为有问题的驱动程序签署 SHA-1 签名，但每当我尝试签署 SHA-256 证书时，我都会收到错误消息：

SignTool 错误：发生了意外的内部错误。错误信息：“错误：SignerSign() 失败。” (-2146893795/0x8009001d)

我已经搜索过这个错误，但它似乎对我来说是独一无二的。由于证书是私人的，我在这里编辑了一些信息。如果我可以提供更多帮助解决问题，请告诉我。

这有效，并使用 SHA-1 签名进行签名：

这些给了我上述错误：

将 /v /debug 添加到命令行提供了额外的输出，但没有提供任何错误帮助。

我在我确认可以访问 Luna 服务器的 Win7 x64 机器上签名。

尝试通过 dpinst（使用 /q）静默安装我的驱动程序在 Windows 7 上失败，但适用于 8.1 和 10。驱动程序已签名，我已将我的证书添加到受信任的发布者列表中。

这是这里和我发现的其他各种文章中推荐的方法。 dpinst / DifX 不会静默安装签名的驱动程序

在非静默模式下，dpinst 会提示您信任发布者并安装驱动程序。在静默模式下，它拒绝安装并给出此错误。

这是从 setupapi.dev.log 中提取的

这仍然是正确的过程还是最近发生了一些变化？

附加信息：所有测试都是在 64 位上完成的，证书是普通代码签名而不是 EV，我使用正确的交叉证书签名，我的证书是 SHA256，但我在 windows 上安装了补丁来支持它。

I have a kext file that was able to load on Mac OS X 10.11.1 but after updating to Mac OS X 10.11.2 it fails to load.

Mac OS X 10.11.1
When executing sudo kextload abc.kext command is successful and when executing sudo kextutil -tn abc.kext the output is /System/Library/Extensions/ch34xsigned.kext appears to be loadable (including linkage for on-disk libraries).

Mac OS X 10.11.2
When executing sudo kextload abc.kext output is /System/Library/Extensions/abc.kext failed to load - (libkern/kext) not loadable (reason unspecified); check the system/kernel logs for errors or try kextutil(8). and when executing sudo kextutil -tn abc.kext the output is Code Signing Failure: not code signed /System/Library/Extensions/ch34xsigned.kext appears to be loadable (including linkage for on-disk libraries).

As far as I understand there was nothing related to drivers signing on this release. The list of changes in this update include:

• Improved Wi-Fi reliability
• Improved the reliability of Handoff and AirDrop
• Fixed an issue that may cause Bluetooth devices to disconnect
• Fixed an issue that prevented Mail from deleting messages in an offline Exchange account
• Fixed an issue that prevented importing photos from an iPhone to a Mac using a USB cable
• Improved iCloud Photo Sharing for Live Photos

Any idea what is going wrong?

我使用这个链接作为参考： DriverSigningAutomation

尝试使用以下代码在 sas uri 上上传 .cab 文件：

我目前面临的几个问题：

1. 如何在显示等待上传的仪表板（ submissionPortal ）上跟踪上传文件的状态？
2. 有什么方法可以让我得到说明文件已成功上传的响应？

问题总结

我的 Windows 应用程序包含一个加载相当简单的驱动程序的服务。此驱动程序包含嵌入式 SHA1 和 SHA256 签名，并包括它们的交叉签名证书链，根据MS Kernel Signing 文档中描述的 KMCS 要求，用于签署没有 CAT 文件的驱动程序。

该驱动程序在大多数 Windows 安装上都可以正常加载，但在极少数情况下无法加载，主要是在 Windows 7 x64 和 Windows 10 x64 上。错误为 0x241 (577)：Windows 无法验证此文件的数字签名。最近的硬件或软件更改可能安装了签名不正确或损坏的文件，或者可能是来自未知来源的恶意软件。

更多信息

在两周的大部分时间里，我一直在试图找出导致这个问题的原因。正如您所料，这个错误只会出现在用户的机器上。我已经安装了 4 台使用 Windows 7 x64 的虚拟机和另外 4 台使用不同配置和不同级别更新的 Windows 10 x64 的虚拟机。我甚至在其中一个 Windows 10 虚拟机中完全复制了用户的设置——我花了一整天时间用正确的语言和他们拥有的所有软件安装了精确的 Windows 版本，以试图复制问题。但是，没有这样的运气：安装我的应用程序时，驱动程序加载得非常好。

希望有人可能对可能发生的事情有所了解，或者至少可以为我指明正确的方向，我决定在这里问：什么可能导致显然正确签名的驱动程序在某些 Windows 上无法通过验证安装？

更多细节

我正在使用 StartCom Class 3 代码签名证书。我从Microsoft Cross-Certificates for Kernel Mode Code Signing页面下载了交叉签名 StartCom 证书。

我的证书在 pfx 文件中，我正在签署驱动程序，如下所示：

由于这不是需要安装的硬件驱动程序，因此它不包含 .CAT 文件或 .INF 文件。它只是一个在服务启动时加载并在服务停止时卸载的驱动程序。

可以注意到，SHA256 签名添加在 SHA1 签名之后（使用 /as），并且它还使用 SHA256 时间戳服务器。它是双重签名的，以便与旧操作系统兼容，尽管我必须说它无法在 Vista x64 中加载，大概是因为我的证书使用 SHA256 作为签名算法。值得注意的是，驱动程序可以在 Windows XP x64 上正常加载。还值得一提的是，在检查文件属性的“数字签名”选项卡时，无法为其加载的所有用户都报告说，这两个签名都得到了很好的验证。我可以在没有 Vista x64 兼容性的情况下生活，但是 Windows 7 和 Windows 10 的问题非常令人担忧，并迫使我将应用程序保持在 beta 测试中。

在各种 Windows 版本的大约 150 多次安装中，我有：

• 在 Windows 7 x64 中验证失败的 3 个用户。其中一个没有安装所有更新，继续安装了大约 200 个更新，之后验证通过并解决了问题。我建议更新给其他 2 个有同样问题的用户，但我没有收到任何反馈，所以我不知道问题是否已解决，我什至不知道他们的 Windows 是否是最新的。
• 3 个在 Windows 10 x64 上无法加载驱动程序的用户。他们所有人都比 Windows 7 用户响应更快，我发现他们所有人都安装了所有更新。使用 Windows 10 周年版安装工具包安装的三个用户中有两个。
• 在 Windows 2003 R2 x86 上无法加载驱动程序的 1 个用户。我还使用此操作系统创建了一个 VM，但未能重现该问题。

每次驱动程序加载失败时，都会在安全事件类别中生成一个审核失败事件，其中包含以下文本：*代码完整性确定文件的图像哈希无效。该文件可能由于未经授权的修改而损坏，或者无效的哈希可能表示潜在的磁盘设备错误。

文件名：\Device\HarddiskVolumeX\Program Files (x86)\path\to\driver.sys*

我在 Vista x64 中遇到了完全相同的错误，并且启用代码完整性详细日志会导致大量关于加载所有 .CAT 文件的消息，而没有其他感兴趣的内容。自然，在 Vista x64 中，代码完整性操作日志包含有关文件未得到验证的错误，与上面的审核错误非常相似。

跑步

结果是：

跑步

结果是：

有点奇怪的是，在没有特殊开关的情况下进行验证会导致证书链错误。再一次，我在检查 VMWare 驱动程序时遇到了同样的错误，所以我想这没什么好担心的。无论如何，运行：

结果是：

我正在使用 VS 2015 附带的 8.1 Windows 工具包中的 signtool.exe，它的版本是 6.3.9600.17298。值得一提的是，该驱动程序是使用 WDK 7.1.0 (7600.13685.1) 编译的。

我们有一个通过 HLK 和 HCK 测试的驱动程序。当我们准备好将其提交给 Microsoft 时，我们会获取 HCK 结果并将它们与 HLK 结果合并，对其进行签名，然后将其提交给 Microsoft。当我们从微软取回驱动程序时，我们得到了两个驱动程序，一个为 win7 签名，另一个为 win10 签名。我们想要一个为 Windows 7 和 Windows 10 签名的驱动程序，因此我们不必担心向我们的客户提供不同的版本。

我们是否错误地合并了我们的.hckx和 HLK 测试结果？我们可以在门户中做些什么来告诉 Microsoft 驱动程序是逐位相同的，我们只希望从它们返回一个二进制文件？