STATUS_NOT_FOUND as "An unexpected internal error" in signtool.exe

Question

My question is related to this one. Alas, that question is about a different CA (Symantec) and uses a different hardware token (from Safenet) and while the provided solution(s) there match the error code, the circumstances of my case don't (among other things the smartcard I was provided with doesn't seem to register its own provider under HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers).

I am using an Open Source code-signing certificate from certum.pl. I am using the signtool.exe from the Windows SDK 10.0.18362.0 and I am seeing the following error (with 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.

The error code 0xC0000225 matches exactly the following NTSTATUS:

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

... which makes perfect sense, given HRESULT codes as used by signtool.exe and the underlying infrastructure map 1:1 to NTSTATUS (of course if a facility code is given, HRESULT codes exist which have no name in ntstatus.h ... what I mean is the layout of HRESULT and NTSTATUS).

Alas, this doesn't tell me anything, since a lot of things may not be found at any given time ... as of this writing I am still trying to narrow it down on my own using ProcMon. For the failing attempt I am seeing 592 NAME NOT FOUND results in ProcMon, which should correspond to the above NTSTATUS code; most of them for registry keys and values.

---

Here's the full signtool command line again:

"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"

... and yes, I verified that it's really using that signtool.exe ... in fact I tried with x86 and x64 with full paths for good measure (my actual script wraps some of the complexities and prepares the environment to adjust PATH to be able to call signtool.exe without its full path).

Strangely enough it works when signing with SHA1 digests like so:

"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"

(differences are the missing /fd sha256 and /td sha256 as well as /t instead of /tr for the timestamping service URL, i.e. different protocol)

The version of the proCertum CardManager software is 3.2.0.156, details as per the following screenshot:

(It's the latest version available from the Certum website at the time of this writing.)

---

I meanwhile tried also with the signtool.exe (x86 and 64 respectively) from:

• Windows 8.1 SDK
• Windows 10.0.17763.0 SDK

... same results and I am puzzled as to how I can resolve this.

Answer 1

Turns out the problem was an option that was not correctly set by default (the name suggested that it only applies to EV certificates, but it appears that it also applies to ones with SHA2 digests). Thanks to the Certum support folks!

I highlighted the relevant option.

Also note, that I had to

1. quit the application (from TNA aka "system tray")
2. start the application elevated from its program folder
3. check the checkbox
4. hit the OK button
5. dismiss the (success) message box
6. reboot

... when I had previously tried without elevation the process failed. And yes, I saw the "shield" icon, but I had assumed that the application contains the logic to perform the elevation (it doesn't).

When I retried signing after a reboot, it was no longer the proCertum CardManager prompting for the card's PIN, but Windows. And signing worked like a charm.

NB: there were still no entries underneath HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers after these steps.