SignTool sporadically reports EXEC This file format cannot be signed because it is not recognized - signtool

I'm using the signtool utility to sign the MSI and EXE files on Teamcity as the part of Continuous Integration process. Most of the time it works as expected but sometimes builds fail with the error message below.
[09:04:00][Exec] C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\MyProject.Setup.AllUsers\..\SigningTool\signtool.exe sign /f C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\MyProject.Setup.AllUsers\..\Certificate\MyCompany.p12 /d "MyCompany" /p MyPassword! /v /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td SHA256 C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\MyProject.Setup.AllUsers\bin\Debug\MyProject.msi
[09:04:00][Exec] The following certificate was selected:
[09:04:00][Exec] Issued to: MyCompany
[09:04:00][Exec]
[09:04:00][Exec] Issued by: Sectigo RSA Code Signing CA
[09:04:00][Exec]
[09:04:00][Exec] Expires: Wed Apr 27 23:59:59 2022
[09:04:00][Exec]
[09:04:00][Exec] SHA1 hash: ***
[09:04:00][Exec]
[09:04:00][Exec]
[09:04:00][Exec] Done Adding Additional Store
[09:04:00][Exec]
[09:04:00][Exec] Number of files successfully Signed: 0
[09:04:00][Exec]
[09:04:00][Exec] Number of warnings: 0
[09:04:00][Exec]
[09:04:00][Exec] Number of errors: 1
[09:04:00][Exec]
[09:04:00][Exec] EXEC This file format cannot be signed because it is not recognized.
[09:04:00][Exec] EXEC An error occurred while attempting to sign: C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\MyProject.Setup.AllUsers\bin\Debug\MyProject.msi
[09:04:00][Exec]
[09:04:00][Exec] C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\packages\WiX.3.11.2\tools\wix2010.targets(2832, 5): error MSB3073: The command "C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\MyProject.Setup.AllUsers\..\SigningTool\signtool.exe sign /f C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\MyProject.Setup.AllUsers\..\Certificate\MyCompany.p12 /d "MyCompany" /p MyPassword! /v /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td SHA256 C:\TeamCity\buildAgent\work\f1f2a8269bd3cd0e\MyProject.Setup.AllUsers\bin\Debug\MyProject.msi" exited with code 1.
Once failed all subsequent builds start failing with the same error message until I restart the build machine. The version of the signtool used is 10.0.17763.132. What is more confusing is when I log in to the build machine and sign the same executables with the same command line it gets signed successfully with no issues.

Something very similar happened to me in a different context. There, too, an executable file became abruptly unserviceable and a system reboot was required.
The cause was a process stopping and waiting for input confirmation with an output file (in your case, this would be the signed executable) still open. The confirmation never came (it was a headless machine) and the process waited forever until a reboot.
We found out the cause by running Process Explorer and checking out all open file handles containing the unwriteable file name. At that point we discovered that it was kept open by another process, and terminating this second process allowed to restart the cycle without rebooting the whole machine.
In the end, in my case, it was the input stream to the hung process that was malfunctioning; we changed the workflow and the problem disappeared.
I suggest as soon as the machine malfunctions again, you run Process Explorer and examine which processes are active and what are they doing.

Related

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

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.
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
quit the application (from TNA aka "system tray")
start the application elevated from its program folder
check the checkbox
hit the OK button
dismiss the (success) message box
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.

error 0x80070005: Adding a tile failed with unexpected error running WACK on Jenkins

Getting "error 0x80070005: Adding a tile failed with unexpected error" here while trying to run appcert (WACK) on an application that is NOT installed within a Jenkins session executing a Windows batch command. I've written a simple C# wrapper to call appcert in elevated user mode. Wrapper and basic command line work outside of Jenkins on the same box in an unelevated cmd window... scratching head...
"C:\Program Files (x86)\Windows Kits\10\App Certification Kit\appcert.exe" reset
if %errorlevel% neq 0 exit /b %errorlevel%
"C:\Program Files (x86)\Windows Kits\10\App Certification Kit\appcert.exe" test -appxpackagepath %WORKSPACE%\UWP_0.9.%BUILD_NUMBER%.0_x86_x64_arm.appxbundle -reportoutputpath %WORKSPACE%\wack.xml
if %errorlevel% neq 0 exit /b %errorlevel%
16:32:04 Successfully reset the testing configuration.
16:32:11 Beginning execution of task Detect app type from package.
16:32:11 Task Detect app type from package execution result was success.
16:32:11 Note: Test application type - UapApp.
16:32:11 Beginning execution of task Extract files from package.
16:32:11 Beginning execution of task Performs AppX deployment/cleanup in the IDE scenario..
16:32:11 Task Extract files from package execution result was success.
16:32:11 Root "Trusted Root Certification Authorities"
16:32:11 Signature matches Public Key
16:32:11 Related Certificates:
16:32:11
16:32:11 Exact match:
16:32:11 Element 7:
16:32:11 Serial Number: 1b659911670d2b9f436f7b922e12ed51
16:32:11 Issuer: CN=ED346674-0FA1-4272-85CE-3187C9C86E26
16:32:11 NotBefore: 1/10/2017 4:01 PM
16:32:11 NotAfter: 1/10/2018 10:01 PM
16:32:11 Subject: CN=ED346674-0FA1-4272-85CE-3187C9C86E26
16:32:11 Signature matches Public Key
16:32:11 Root Certificate: Subject matches Issuer
16:32:11 Cert Hash(sha1): 7a 5f 2f 31 7a 88 82 fd e5 12 f6 fb 2d 37 46 1f 29 ff
01 ef
16:32:11
16:32:11 Certificate "ED346674-0FA1-4272-85CE-3187C9C86E26" already in store.
16:32:11 CertUtil: -addstore command completed successfully.
16:32:11 Task Performs AppX deployment/cleanup in the IDE scenario.
execution result was failure.
16:32:11
16:32:11 error 0x80070005: Adding a tile failed with unexpected error.
I can't verify it by myself, but most likely the command line below with missing double quotes is the reason for the failure.
"C:\Program Files (x86)\Windows Kits\10\App Certification Kit\appcert.exe" test -appxpackagepath %WORKSPACE%\UWP_0.9.%BUILD_NUMBER%.0_x86_x64_arm.appxbundle -reportoutputpath %WORKSPACE%\wack.xml
The value of environment variable WORKSPACE referenced twice with %WORKSPACE% contains the full path to current workspace folder of the current Jenkins job.
And I suppose this folder path contains 1 or more spaces which requires enclosing both parameter strings in double quotes to be correct passed to appcert.exe.
For that case this command line is definitely better:
"%ProgramFiles(x86)%\Windows Kits\10\App Certification Kit\appcert.exe" test -appxpackagepath "%WORKSPACE%\UWP_0.9.%BUILD_NUMBER%.0_x86_x64_arm.appxbundle" -reportoutputpath "%WORKSPACE%\wack.xml"
However, I found with a very simple and quick search with my favorite www search engine the page Error 0x80070005 with Windows App Certification Kit among many others where it is written that error code 0x80070005 literally means "Access Denied" on a resource.

Dual-sign .cat file has error "No signature was present in the subject"

I'm dual-signing a windows .sys and .cat files for a driver using a certificate purchased from Symantec with the following command lines (the sys and cat files are both signed with the same options):
signtool.exe sign /v /ph /n "MyCorp" /ac "C:\Signing\VeriSign Class 3 Public Primary Certification Authority - G5.cer" /i "VeriSign Class 3 Code Signing 2010 CA" /t "http://timestamp.verisign.com/scripts/timstamp.dll" "MyDriver.cat"
signtool.exe sign /v /ph /n "MyCorp" /ac "C:\Signing\VeriSign Class 3 Public Primary Certification Authority - G5.cer" /i "Symantec Class 3 SHA256 Code Signing CA" /tr "http://timestamp.geotrust.com/tsa" /as /fd sha256 /td sha256 "MyDriver.cat"
Signtool.exe reports success when it exits. When I view the signatures by right clicking the signed files, choosing Properties, go to Digital Signatures tab, then I see the two signatures. The sha1 signature seems fine. When I view the details of the sha256 certificate on the .sys file, everything looks good. But, when I view the details of the sha256 certificate on the .cat file, I see the following error:
The driver won't install on a Window7 box that I configured to believe SHA1 was deprecated on 1st January 2015 (rather than the real date when they expire which is 1st Jan 2016).
I saw a note on this msdn page saying:
Note that only .sys files can be dual signed because they are PE
files.
Is that quote trying to say in a roundabout way that .cat files cannot be dual signed?
How should cat files be signed so that they will install on all versions of windows?
It does seem that .cat files cannot be dual signed.
My solution was to sign the .cat file using a SHA256 certificate, but with signtool command line options to create a SHA1 signature.
The .sys file associated with the driver I was still able to dual sign.
This seems to be working in all the scenarios I need.
Is this only a visual/cosmetic issue or does your driver installation fail ?
A probably better and more solid alternative to dual-signing is an installer that includes both sha1- and sha2-signed binaries which installs the correct set depending on the os version. Since the major parts of the binaries are identical the compressed installer size also won't increase too much.
cat files shall be double signed using the following procedure:
inf2cat.exe /driver:__Path__ /os:__WindowsVersions__
signtool.exe sign /v /ac __RootCert__ /t __TimeStampLink__ /sha1
__Sha1ThumbPrint__ __CatFile__
signtool.exe sign /v /ac __RootCert__ /tr __TimeStampLink__ /td sha256
/fd sha256 /as /sha1 __Sha2ThumbPrint__ __CatFile__
Use the signing tools from windows kit v10.x (or above) to perform this.

Signing executable with PKCS #7 SPC file using console version of signtool.exe

I am trying to sign an executable with PKCS #7 SPC file issued at Go Daddy. I have CSR (code signing request) file and PrivateKey.key file and .pem file with same name as .spc file. I am trying to use console version of signtool.exe:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin>signtool sign /t http://tsa.starfieldtech.com /csp "D:\SOMENAME.spc" /k "D:\SOMENAME.key" /sha1 HASH_MATCHING_RIGHT_CERT /v file_to_sign.exe
The following certificate was selected:
Issued to: Monster, Inc.
Issued by: Go Daddy Secure Certification Authority
Expires: Fri Dec 21 06:06:06 2014
SHA1 hash: HASH_MATCHING_PARAMETER
SignTool Error: No private key is available.
I had previously installed spc file into My store. I got code signing certificate and two Go Daddy certificates.
What am I missing and what steps should I take?
I needed to convert those two PKCS #7 keys to .pfx format using OpenSSL, and then use the more common way of signing using folowing command:
signtool sign /t http://tsa.starfieldtech.com /d "Description" /du "www.url.com" /f "cert.pfx" /p password /v file.exe

Why is my code signing (MS authenticode) verification failing?

I posted this question and have a freshly minted code signing cert from Thawte.
I followed the instructions (or so I thought) and the code signing claims to succeed, however when I try to verify the tool shows an error.
The results from the verification step seem to show it is correct, however there is an error and no explanation whatsoever about why the error exists.
Any comments or suggestions are much appreciated.
Command line to sign exe:
signtool sign /f mdt.pfx /p password /t http://timestamp.verisign.com/scripts/timstamp.dll test.exe
Results:
The following certificate was selected:
Issued to: [my company]
Issued by: Thawte Code Signing CA
Expires: 4/23/2011 7:59:59 PM
SHA1 hash: 7D1A42364765F8969E83BC00AB77F901118F3601
Done Adding Additional Store
Attempting to sign: test.exe
Successfully signed and timestamped: test.exe
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
Note that there are no errors or warnings.
Now, when I try to verify imagine my surprise:
signtool verify /v test.exe
results in:
Verifying: test.exe
SHA1 hash of file: 490BA0656517D3A322D19F432F1C6D40695CAD22
Signing Certificate Chain:
Issued to: Thawte Premium Server CA
Issued by: Thawte Premium Server CA
Expires: 12/31/2020 7:59:59 PM
SHA1 hash: 627F8D7827656399D27D7F9044C9FEB3F33EFA9A
Issued to: Thawte Code Signing CA
Issued by: Thawte Premium Server CA
Expires: 8/5/2013 7:59:59 PM
SHA1 hash: A706BA1ECAB6A2AB18699FC0D7DD8C7DE36F290F
Issued to: [my company]
Issued by: Thawte Code Signing CA
Expires: 4/23/2011 7:59:59 PM
SHA1 hash: 7D1A42364765F8969E83BC00AB77F901118F3601
The signature is timestamped: 4/27/2010 10:19:19 AM
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: 12/31/2020 7:59:59 PM
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: VeriSign Time Stamping Services CA
Issued by: Thawte Timestamping CA
Expires: 12/3/2013 7:59:59 PM
SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D
Issued to: VeriSign Time Stamping Services Signer - G2
Issued by: VeriSign Time Stamping Services CA
Expires: 6/14/2012 7:59:59 PM
SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE
Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1
Try Signtool verify /v /pa foo.exe
From Using SignTool to Verify a File Signature (emphasis is mine)
SignTool verify MyControl.exe
If the preceding example fails, it
could be that the signature used a
code-signing certificate. SignTool
defaults to the Windows driver policy
for verification.
The following command verifies the
signature, using the default
authentication verification policy:
SignTool verify /pa MyControl.exe

Resources