在signtool.exe中，STATUS_NOT_FOUND被翻译为“意外的内部错误”。

Question

我的问题与这个问题有关。遗憾的是，那个问题涉及不同的CA（Symantec），并使用不同的硬件令牌（来自Safenet）。虽然提供的解决方案与错误代码匹配，但我所处的情况并不匹配（除其他事项外，我提供的智能卡似乎没有在HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers下注册其自己的提供程序）。

我正在使用来自certum.pl的开源代码签名证书。我正在使用Windows SDK 10.0.18362.0中的signtool.exe，并且我看到以下错误（使用signtool sign /v /debug）：

signtool.exe sign /v /debug /a /i Certum /ph /du "https://my.url" /d "short description" /fd sha256 /tr "http://timestamp.digicert.com" /td sha256 "mysoftware.exe"
The following certificates were considered:
    Issued to: Open Source Developer, ...
    Issued by: Certum Code Signing CA SHA2
    Expires:   ...
    SHA1 hash: ...
    Issued to: Open Source Developer, ...
    Issued by: Certum Code Signing CA SHA2
    Expires:   ...
    SHA1 hash: ...
After EKU filter, 2 certs were left.
After expiry filter, 1 certs were left.
After Issuer Name filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
    Issued to: Open Source Developer, ...
    Issued by: Certum Code Signing CA SHA2
    Expires:   ...
    SHA1 hash: ...
Done Adding Additional Store
Error information: "Error: SignerSign() failed." (-1073741275/0xc0000225)
SignTool Error: An unexpected internal error has occurred.

错误代码0xC0000225完全匹配以下NTSTATUS：

//
// MessageId: STATUS_NOT_FOUND
//
// MessageText:
//
// The object was not found.
//
#define STATUS_NOT_FOUND                 ((NTSTATUS)0xC0000225L)

这很有道理，因为signtool.exe使用的HRESULT代码和底层基础设施映射到NTSTATUS是1:1的（当然，如果给定了一个设施代码，则存在HRESULT代码，在ntstatus.h中没有名称...我的意思是HRESULT和NTSTATUS的布局）。

但遗憾的是，这并没有告诉我任何东西，因为许多东西可能在任何给定时间都找不到...截至本文撰写时，我仍在尝试使用ProcMon自己缩小范围。对于失败的尝试，我在ProcMon中看到了592个NAME NOT FOUND结果，这应该对应于上面的NTSTATUS代码；其中大部分是注册表键和值。

---

这里再次提供完整的signtool命令行：

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe" sign /v /debug /a /i Certum /ph /du "https://my.url" /d "short description" /fd sha256 /tr "http://timestamp.digicert.com" /td sha256 "mysoftware.exe"

...是的，我验证了它确实使用了那个signtool.exe...事实上，我尝试了x86和x64，并带有完整路径以确保万无一失（我的实际脚本包装了一些复杂性，并准备好环境来调整PATH，以便能够调用signtool.exe而不需要其完整路径）。

奇怪的是，当使用SHA1摘要进行签名时，它可以正常工作，如下所示：

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe" sign /v /debug /a /i Certum /ph /du "https://my.url" /d "short description" /t "http://timestamp.digicert.com" "mysoftware.exe"

（差异在于缺少/fd sha256和/td sha256，以及时间戳服务URL的/t而不是/tr，即不同的协议）

proCertum CardManager软件版本为3.2.0.156，详细信息如下截图所示：

（这是目前为止从Certum网站上获取的最新版本。）

---

我同时也尝试了来自以下SDK的signtool.exe（分别为x86和64位）：

• Windows 8.1 SDK
• Windows 10.0.17763.0 SDK

......结果相同，我很困惑该如何解决。

- 0xC0000022L

Answer 1

原文已经解决了一个默认未正确设置的选项问题（选项名称暗示它仅适用于EV证书，但似乎也适用于具有SHA2摘要的证书）。感谢Certum支持人员！

我突出了相关选项。

还要注意，我必须

1. 退出应用程序（从TNA即“系统托盘”）
2. 从其程序文件夹以提升权限启动应用程序
3. 勾选复选框
4. 点击确定按钮
5. 关闭（成功）消息框
6. 重新启动

...当我之前尝试没有提升权限时，该过程失败了。是的，我看到了“盾牌”图标，但我认为应用程序包含执行提升的逻辑（实际上没有）。

当我重新启动后重试签名时，不再是proCertum CardManager提示输入卡的PIN码，而是Windows。并且签名工作得很好。

NB：在这些步骤之后，HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers下仍然没有条目。

- 0xC0000022L