我的公司从 Go Daddy购买了司机签名证书。我用它签署了一个简单的 INF 文件，该文件是我们使用 Microsoft 的 usbser.sys 的一些 USB 设备的驱动程序。一切似乎都在我签署它的 Windows 7 64 位计算机上运行：如果我右键单击 INF 文件并选择“安装”，那么我看到的第二个警告是这个显示正确发布者名称的好警告：

但是，如果我转到另一台计算机（Windows Vista 64 位），右键单击 INF 文件，然后选择“安装”，然后我会收到以下错误消息：

这让我觉得我的驱动程序没有正确签名，它在我的计算机上看起来不错的唯一原因是因为我在 Go Daddy 的安装过程中安装了一些根/中间/交叉证书。我绝对希望我的用户能够看到我们是经过验证的发布者，而无需在他们的计算机上手动安装证书。

INF 文件和 .cat 文件在同一目录中。

有谁知道为什么会发生这种情况以及我该如何解决？

我怀疑主要问题是我在运行时收到此错误signtool verify /v pololu.cat（下面有更多详细信息），我还没有弄清楚原因：

SignTool 错误：已处理证书链，但在信任提供者不信任的根证书中终止。

我的程序的详细信息

司机签名证书是 Go Daddy 几周前推出的新产品。我不完全确定它与Code Signing Certificate有何不同，但价格相同。我按照Go Daddy 网站上的说明下载并安装了证书，但说明与实际情况并不完全相符。在步骤 1 中安装 Microsoft 交叉证书后，我看到一条红色警告消息，上面写着：

在安装证书之前，您必须使用 Windows 更新更新您的根证书或从我们的存储库手动下载并安装根证书。

我不知道该怎么办。我确实从他们的存储库中安装了一些 GoDaddy 根证书，但没有明显区别。

我安装了Windows Driver Kit (WDK)的最新版本 (8.0)，然后安装了适用于 Windows 8 的 Windows Software Development Kit (SDK)的最新版本 (8.0) 。这使我可以访问inf2cat和signtool实用程序。这两个工具包都是在上个月发布的，所以我们可能正在处理一些新的错误。

在一个新目录中，我放了三个文件：

1. pololu_usb_to_serial.inf，我要签名的INF文件。它很长但很简单；你可以在这里阅读。这个 INF 文件是一个独立的驱动程序；我们的驱动程序包中不需要其他文件。该文件与我们公司多年来成功分发（未签名）的版本基本相同，但我必须对 Inf2Cat 进行一些更改才能接受它。
2. mscvr-cross-gdroot-g2.crt，我从Go Daddy 证书存储库下载的。我相信这是证明“Go Daddy Root Certificate Authority - G2”受微软信任的交叉证书，但我不完全确定这是否是正确的证书。
3. sign_it.bat，我运行的批处理文件进行签名。

批处理文件只包含：

第一个命令inf2cat从 Windows Driver Kit 调用。该/v选项使其变得冗长。该/driver:%~dp0选项将其指向包含批处理文件的目录；a.由于某种原因不起作用，这比对完整路径进行硬编码要好。该/os选项指定了我希望使用此驱动程序包支持的所有操作系统。此命令创建pololu.cat.

第二个命令signtool从 Windows 软件开发工具包调用以对目录文件进行签名。该/v选项使其变得冗长。该/ac选项指定使用哪个交叉证书（参见上面的#2）。该/n选项指定要使用的证书的名称（该证书根据 安装在我的计算机上certmgr.msc）。该/t选项指定 Go Daddy 时间戳服务器的 URL。

这是我运行批处理文件时命令提示符中的输出：

正如我所说，我将 .cat 和 .inf 文件一起保存在同一个目录中，但它们只有在我签名后才能在计算机上正常工作。

使用 Signtool 进行验证

Microsoft的signtool实用程序还具有“验证”功能，可让您验证您的签名是否正确。验证时可以使用三种不同的策略，它们各自给出不同的结果：

• Windows 驱动程序验证策略说我的签名链不会追溯到 Microsoft，并打印一条错误消息，说明我的 root 是如何不受信任的。这对我来说似乎是个问题。
• 默认 Authenticode 验证策略( ) 还说我的/pa签名链不会追溯到 Microsoft，但它没有给出错误。
• 内核模式驱动程序签名策略（可能不适用，/kp因为我没有签署内核模式驱动程序）说我的签名链确实可以追溯到 Microsoft，并且没有给出错误。

有谁知道 Windows 对 INF 文件使用哪种策略？这至少可以帮助我缩小问题的范围。

以下是来自的完整、详细的输出signtool verify：

在我签署驱动程序的计算机（它正在工作的地方）和另一台计算机（它不工作的地方）上运行时，输出看起来相同。

StackOverflow 上的类似问题

Thawte 64 位 Windows 驱动程序签名- 这个人的问题的解决方案是将 CatalogFile 指令添加到 INF 文件，但我已经有了。( CatalogFile=pololu.cat)。

编辑#1：签署可执行文件有效

我使用带有相同选项的 signtool 来签署可执行文件（NSIS 安装程序），它在两台计算机上的第一次尝试中都能正常工作。所以我认为 INF 驱动程序文件的签名策略有些不同，这就是让我搞砸的原因。

编辑 #2：GoDaddy 证书上的警告

如果我双击mscvr-cross-gdroot-g2.crt，在“常规”选项卡中会显示“Windows 没有足够的信息来验证此证书”。在“证书路径”选项卡的“证书状态：”下，显示“找不到此证书的颁发者。”。如果我双击gd_ms_drv_sign_bundle.p7b（来自 GoDaddy 的证书包）并打开第一个证书，我也会看到相同的警告。

这两个证书的颁发者应该是 Microsoft 代码验证根。我应该担心那个警告信息吗？

编辑#3：删除 GoDaddy 的证书

GoDaddy 高级支持团队的 Lindsay 回复了我。她从 globalsign 链接到此页面，该页面解释了如何在签署驱动程序的计算机上从 CA 卸载根证书和中间证书。Lindsay 说，如果您不执行此步骤，签名工具将假定这些证书存在于其他计算机上，因此不会将它们包含在签名中。

有谁知道如何检查哪些证书被“导入”到签名中？我可以使用哪些工具来查看 Lindsay 和 GlobalSign 是否正确？

顺便说一句，我们周围有 Windows XP 计算机，但微软很快就会停止支持该操作系统。尽管 GlobalSign 说了什么，但必须有一种方法可以在 Windows 7 上完成这项工作。

根据 Lindsay 的建议，我按照 Microsoft 的说明关闭自动根证书更新，然后使用 UIcertmgr.msc删除“受信任的根证书颁发机构”和“中级证书颁发机构”中的所有 GoDaddy 证书。然后我重新签署了我的 inf 文件。

不幸的是，那没有用！签名后，我仔细检查了所有 GoDaddy 证书是否仍被删除。

我没有收到来自 GoDaddy 的关于 的输出的反馈signtool verify，或者我在进行验证时应该检查的驱动程序签名策略的任何输入。我希望他们可以只查看验证输出并告诉我我做错了什么，或者告诉我正确的输出是什么样的。

signtool verify为了完整起见，以下是我删除这些证书并重新签署驱动程序后的三个输出：

编辑#4：DefaultInstall 部分是禁止的

在Microsoft的 DefaultInstall 部分的文档中，我发现了这一点：

注意如果要对驱动程序包进行数字签名，则驱动程序包 的 INF 文件不得包含 INF DefaultInstall部分。

有谁知道为什么这是真的？我找不到解释。

无论如何，我取出了我的 INF 文件的 DefaultInstall 部分，所以从现在开始我必须通过运行我编写的一个名为 SetupCopyOemInf的小 DLL 来测试它。

仍然没有运气；我不断在 Windows Vista 计算机上收到未经验证的发布者警告。

编辑 #5：JLink 驱动程序已正确签名

我在 C:\Windows\System32\DriverStore\FileRepository 中四处寻找，试图找到一些正确签名的驱动程序包。我发现的第一个有趣的是 JLinkCDC.cat/JLinkCDC.inf。Inf 文件的版本是DriverVer=01/25/2012,6.0.2600.4. 在 Windows Vista 机器上，如果我在 inf 文件上调用 SetupCopyOemInf（使用我的 DLL），那么我会收到一条正确的消息，告诉我发布者是谁（Segger GMBH 或类似的东西）。因此，可以正确签署像我这样的驱动程序包，但不知何故 GoDaddy 或我做错了什么。

JLinkCDC.inf 驱动程序和我的驱动程序非常相似，因为它只是一个文件并且使用了 usbser.sys。他们签名的信任链可以追溯到 VeriSign Class 3 Public Primary Certificate Authority - G5。

基本上，这个 JLinkCDC 驱动程序和我的很相似并且可以工作，所以我打算仔细研究一下，看看有什么不同。

JLinkCDC.cat 的 signtool verify的输出看起来与我的非常相似，只是它追溯到 Verisign 而不是 GoDaddy。

编辑#6：微小的变化

为了使我的驱动程序更像 JLinkCDC.inf，我添加DriverPackageType=PlugAndPlay到 INF 文件并缩短了文件名：这些文件现在称为 polser.cat 和 polser.inf。还是没有运气！

编辑#7：一些成功！

我认为以下几点是正确的；如果我错了，请纠正我：

• 对于驱动程序包（.cat 文件），正确的选项signtool verify是/pa. 我从KMCS_Walkthrough.doc推断出这一点。
• 对于驱动程序包，如果信任链返回到 certmgr.msc 中“受信任的根证书颁发机构”文件夹中的证书，Windows 只会考虑验证发布者。
• 对于驱动程序包，您可以使用交叉证书对其进行签名（将信任链从 gdroot-g2.crt 扩展到 Microsoft 代码验证根），但 Windows 似乎忽略了这一点。这是因为 Microsoft 代码验证根不是“受信任的根证书颁发机构”。
• 有当前用户的证书存储和本地计算机的证书。它们都很重要，因此您应该使用MMC 证书管理单元来查看两者。Certmgr.msc 仅显示当前用户的那些。
• Windows应该在需要时将“Go Daddy 根证书颁发机构 - G2”(gdroot-g2.crt) 无缝添加到“受信任的根证书颁发机构”文件夹中，从 Windows 更新下载它，但它没有。 更多信息在这里。

我在测试机器上使用了 Windows 事件查看器来查看发生了什么。看起来 Windows 会自动获取“Go Daddy Root Certificate Authority - G2”，但只有在它显示不受欢迎的未经验证的发布者警告对话框之后。一旦用户关闭该对话框，就会从 Windows 更新中获取证书，因此下一次安装尝试应该会成功。有趣的是，它确实会及时自动下载 Starfield 证书（它是我的时间戳的信任链的根）。

通过双击 gdroot-g2.crt 并在尝试安装驱动程序之前将其导入，我已经获得了在 Windows 7 和 Windows Vista 计算机上工作的签名。我会看看这个过程是否可以自动化并添加到安装程序中。

我找到了来自另一家公司 (JLinkCDC.cat) 的驱动程序包，该驱动程序包使用 VeriSign 证书签名，该证书植根于“VeriSign Class 3 Public Primary Certification Authority - G5”。该证书在我查看过的所有计算机上，因此如果您使用 VeriSign 而不是 Go Daddy，我认为您可以使用 Windows Update 避免这个问题。

我确实注意到 VeriSign 证书使用 SHA1，而我的 Go Daddy 证书使用 SHA256 作为签名算法和签名哈希算法。不确定这是否重要。

编辑#8：向微软寻求帮助

请参阅 MSDN 论坛上的讨论和我的结论：http: //social.msdn.microsoft.com/Forums/en-US/wdk/thread/1fede768-7925-4f30-8eef-ce5bd08b0b60

我正在尝试解析 WiX RemotePayload 哈希，但我不确定如何CertificatePublicKey找到该属性。

例如，来自 WiX 3.6 源的 .NET 4.0 包定义：

来自wix36-sources\src\ext\NetFxExtension\wixlib\NetFx4.wxs

我可以找到 sha1 Hash...fciv -sha1 dotNetFx40_Full_x86_x64.exe

58da3d74db353aad03588cbb5cea8234166d8b99 dotnetfx40_full_x86_x64.exe

CertificateThumbprint我可以通过文件的属性对话框轻松找到匹配项，或者使用signtool它显示以下输出

什么工具可以提供哈希CertificatePublicKey？

编辑：不使用热量，我想了解哈希的来源。

编辑：我知道这是如何在 WiX 源代码中完成的并且我可以执行
heat payload file -out file.wxs，但我正在寻找一些可以在不使用热量的情况下提供预期哈希的外部工具。这真的只是为了满足我的好奇心。

直接在构建服务器上安装 Authenticode 代码签名证书以创建生产签名构建是否可以接受？我正在网上寻找一些资源，这些资源建议或支持这种做法是合法的，前提是您已采取适当的步骤来保护构建服务器以及创建和部署构建的过程。

我能找到的关于代码签名实践的所有“最佳实践”指南在建议的过程方面都远远超过了顶部。Microsoft 的参考文档有多达 6 个服务器在使用，用于签署单个程序集的简单操作。 http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc

一些背景：

我的公司为其员工和直接客户创建了简单的富客户端业务线应用程序。我们不创建商业软件。我的构建服务器使用我的公司严格的安全策略和程序进行物理安全和网络安全。只有组织中非常具体的人才能在我的环境中开始构建。

我们当前的流程要求我将构建/部署流程分解为多个阶段，并配备大量手动流程。我们使用物理设备来存储 Authenticode 证书，需要用户输入 PIN 才能访问。我们必须将需要代码签名的程序集/清单改组到指定的代码签名 PC，这些 PC 也必须受到物理保护。

对我来说，传递物理令牌/设备并保留所有这些手动步骤是不太安全的。没有什么可以阻止对令牌/设备具有物理访问权限的人签署他们想要的任何东西。至少，通过自动化、记录、受控的构建服务器环境，您知道签名的内容和签名者。

我开发了一个软件应用程序，并使用从 Verisign（现为 Symantec）获得的 Authenticode 证书对我的安装程序进行了数字签名。我使用 Visual Studio 附带的 signtool.exe 实用程序对安装程序 (.exe) 进行了签名。当我运行安装程序时，它现在将我的公司名称显示为发布者，而不是“未知”，这是我的目标....成功！

然后我在我的网站上发布了安装程序文件以分发给我的客户。该文件由一个 asp:button 提供服务，单击该按钮将执行以下代码：

当我从我的网站下载安装程序文件并运行它时，发布者字段显示“未知”！！！然后我使用 FTP 客户端将文件直接从我的网络服务器复制到我的计算机，下载的文件有签名（即没有显示发布者：未知），所以显然网络服务器上的文件很好。它一定是关于通过网站下载文件的过程，该过程会去除或使数字签名无效。我尝试了 Firefox 和 IE 并得到了相同的结果。

我究竟做错了什么？提前感谢你的帮助。

我已经安装了openssl，现在rsa_test.c运行良好。我想做的是：

1. 打开任何 exe 或 dll 数字证书。提取指纹和公钥。公钥也包含指数（如果您熟悉 ASN1 编码）。

2. 现在我已经计算了文件的SHA-1哈希值并将其与 MD 字段进行比较以发现它是正确的。所以现在我想将Thumbprint、PublicKey->m和PublicKey->e传递给RSA_public_decrypt函数来计算文件的解密SHA-1哈希值。

我应该将什么填充算法传递给函数？当我通过RSA_NO_PADDING时，它会解密但给我 128 字节长的散列，这根本不正确。对于所有其他填充算法选项，它返回未找到填充的错误。

请您教我或告诉我正确的参数以通过示例或良好的示例链接传递函数？

我有一个加载外部 DLL（一种插件系统）的进​​程，我想验证加载的 DLL 是否使用 Authenticode 正确签名。在仔细阅读 WinVerifyTrust和LoadLibrary（和朋友）的文档后，让我印象深刻的一件事是这两个操作都从文件路径到 DLL 工作。

在我看来，利用它来使我的程序加载一个未签名的 DLL 是非常可行的，方法是向程序提供一个签名的 DLL，导致成功并在调用执行WinVerifyTrust()之前立即用未签名的代码替换 DLL （这是一个LoadLibrary()硬竞争条件，但如果攻击者对文件系统有一些控制权，例如在使用网络文件系统时，它可以得到更好的控制）。

的 APIWinVerifyTrust()似乎表明我可以在打开文件的句柄上运行验证过程。如果我可以打开文件，验证打开的文件句柄，然后从同一个文件句柄加载库 - 那么我将是安全的。不幸的是LoadLibraryEx()——这将是我实现这一点的主要嫌疑人——将其hFile参数记录为“保留供将来使用”。

我的下一个想法是将文件内容加载到内存中，然后从内存中加载 DLL，我找到了执行此操作的库MemoryModule。我想知道是否有一些现有的实现已经完成并结合了所有这些，并允许开发人员安全地验证和加载 DLL，这意味着我不必自己编写和维护它。

有什么建议么？

好吧，我做的不对，我需要一些帮助。这是正在发生的事情：

1. 我有一张来自Comodo的“真正的”Authenticode 证书，我已经支付了费用。
2. 我正在尝试签署和部署用 Visual Studio 2012 和 .NET 4.5 编写的 WPF 应用程序。
3. 在项目的属性中，我检查了“签署 ClickOnce 清单”并选择了我的证书。
4. 我也在使用 Comodo 的时间戳服务器（http://timestamp.comodoca.com/authenticode）
5. 在“发布”选项卡和“先决条件”按钮下，我已选中“创建安装程序以安装必备组件”。

当我构建和发布时，一切正常！setup.exe 使用我的 Comodo 证书签名，这很好。此外，该.application文件使用 Comodo 证书签名，并且我的公司名称显示为发布者——这也很好。

问题来了：一旦将应用程序下载到客户端，Windows 8 就会发出关于不受信任程序 (MyProgram.exe) 的警告，并且发布者不是我的公司名称。因此，除了实际的可执行文件外，所有内容都已签名。

我尝试在 obj\Release\MyProgram.exe 上添加使用 signtool.exe 的构建后脚本，但是当我尝试安装应用程序时，我收到一个清单错误，指出哈希值不匹配。换句话说，清单是在构建后事件之前生成的。

如何签署我的 .exe 并维护 ClickOnce 清单的完整性？有没有一种简单的方法可以做到这一点，或者我必须手动在每个文件上使用 mage.exe（我希望不是）？

我的代码签名证书有效期为 2012 年 3 月 3 日至 2013 年 3 月 3 日（Comodo）

1. 更新它会给我一个新证书（.pfx 文件）吗？或者我可以在支付费用后在 2013 年 3 月 3 日之后使用当前证书（.pfx 文件）吗？

2. 如果我不使用新证书签署 exe 和设置，或者我不购买新证书，现有签名的应用程序会在 2013 年 3 月 3 日之后的安装/执行期间显示“未经验证的发布者”或任何其他错误。请注意，我签署了软件的所有 dll、exe 以及最终设置 exe

3. 我是否必须在续订时获取新的 .snk 文件，还是可以使用现有的 .snk 文件？

4. 我可以使用相同的 .snk 文件来签署不同的软件及其设置文件吗？和不同的exe，dll在同一个设置中？.snk 文件是否与一个 exe 相关联？还是可以在任何exe（.NET和VB6）上使用？

我有 Windows 8 Pro + Visual Studio 6 SP6 + Visual Studio 2012 Ultimate + Microsoft 8 SDK 独立安装

我的问题是关于在 .NET 程序集之间强制执行安全性。这是场景：

• Foundation程序集部署在服务器上。
• 一系列插件程序集在应用程序中提供。
• 插件使用Foundation的功能。
• 由于基金会提供敏感操作和数据，它必须确保插件（调用者程序集）是真实的并且来自某个发布者。

我对安全性很陌生，对强命名和数字签名有基本的了解。因此，如果您能详细解释实现上述目标的可能方法，我将不胜感激。

我从http://www.ksoftware.net/购买了一个证书，我用它来签署一个 .CAB 文件，用于在 windows mobile 6.5 设备上安装我们的软件。但是，即使在签署 .CAB 之后，当尝试（通过 CAB）在设备上安装应用程序时，设备也会警告“未知发布者”。这些 CAB 文件是从 Web 服务下载的，并且应该使用 wceload 及其静默安装选项自动安装，但是由于 CAB 未被识别为已签名（一旦我手动安装了特定的 CAB 文件，wceload 将为此成功）未来的驾驶室）。

最初，我只在 Visual Studio 2008 部署属性和应用程序签名属性中设置了证书。我还尝试使用 signtool.exe，然后使用 cabsigntool.exe 对 CAB 中的所有其他文件进行签名。这些方法都不起作用。在 Windows 7 中检查 CAB 的属性时，该文件确实附加了安全证书，但任何尝试在设备上安装都会出现烦人的“未知发布者”弹出框。

有什么我想念的吗？什么可能导致设备仍将 CAB 文件视为未签名？签名似乎也不适用于普通的 exe。

请注意，我知道可以更改安全设置以不出现提示，但我有兴趣解决安全证书问题。