My boss has procured a certificate from Comodo and I've been breaking myself against walls of text trying to find the solution to the problem of getting the certificate into a VB6 application. The certificate itself is in VB6 format and I know like next to nothing about this type of thing. The people at Comodo were just OH so helpful (From my boss, they said he can find something on the internet. Apparently they don't know how big the internet is -.-)
Does signing the project require putting code into the program, or is it just the .exe that gets signed by the MS Authenticode executable files?
Does anyone have like an idiots step by step guide solution for this?
Thanks in advance.
Here is a snippet from our build scripts
set signtool=C:\{cert_path}\signtool.exe sign /f C:\{cert_path}\my_code_sign_current.p12 /p ###### /du "http://mycompany.com" /t "http://timestamp.comodoca.com/authenticode"
%signtool% /d "My Application 1.0" "C:\{binn_path}\App.exe"
%signtool% /d "My Other App 2.0" "C:\{binn_path}\Other.exe"
...
We use older version of signtool.exe (6.0.4002.0) because we had troubles using some timestampimg servers with newer versions (http://www.startssl.com/timestamp).
Note: .pfx and .p12 files -- these are the same PKCS #12 container files, DER encoded
Related
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.
I'm using signtool.exe on Windows to code sign with a SHA256 signature.
The only example I see (from Symantec) shows using:
http://timestamp.geotrust.com/tsa
..as the time server.
E.g.: signtool.exe sign /a /s MY /n "Common name" /as /fd sha256 /tr http://timestamp.geotrust.com/tsa /v "<file to be signed>"
But I'm wondering if there are other publicly supported RFC 3161 timestamp servers that will also work.
I'm asking because we had previously built redundancy into our code signing process when using SHA1 by having a few different servers (and multiple retry attempts + delays). This helped resolve very occasional but annoying build failures.
I want to do the same when code signing with SHA256.
Found this additional RFC 3161 timeserver:
http://timestamp.comodoca.com/rfc3161
Source: http://zabkat.com/blog/code-signing-sha1-armageddon.htm
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.
I can't get windows 8 (release preview) to accept either the inf2cat or makecat approach described as solutions to the question at
What changed in the driver signature requirements for Windows 8?
unless I disable validation.
I am not signing these with any certificates at this point, just trying to get past the errors preventing the drivers from installing at all.
Windows 8 gives me a very nondescript error:
"A problem was encountered while attempting to add the driver to the store."
Looking in the event logs, there is nothing of use; only an informational entry from "Windows Error Reporting" indicating a PnPdriverimporterror.
When i use my original files with the cab files that don't match the inf, I get the error everyone else is listing:
The hash for the file is not present in the specified catalog file.
I have one .inf file that i need to generate a .cat for.
Perhaps I am doing something wrong. Ideas??
INF2CAT Approach
c:\win_xp_vista32_64>inf2cat /driver:"." /os:XP_X86,XP_x64,Vista_X86,Vista_x64,7_X86,7_X64,8_X86,8_X64
.......................
Signability test complete.
Errors:
None
Warnings:
22.9.10: usbser.sys in [drivercopyfiles.nt] is missing from [SourceDisksFiles] s
ection in \mchpcdc.inf; ok if file source is provided via LayoutFile in [Version
].
22.9.10: %driverfilename%.sys in [drivercopyfiles.ntamd64] is missing from [Sour
ceDisksFiles] section in \mchpcdc.inf; ok if file source is provided via LayoutF
ile in [Version].
Catalog generation complete.
c:\win_xp_vista32_64\mchpcdc.cat
MAKECAT approach
--- start of catalog.cdf file---
[CatalogHeader]
Name=mchpcdc.cat
ResultDir=.\
[CatalogFiles]
<hash>mchpcdc=.\mchpcdc.inf
---end of .cdf file ---
c:\win_xp_vista32_64>makecat catalog.cdf
These same files, w/ the cat from either approach install just fine in Windows 7.
I think this problem is to do with "windows driver signing enforcement". You can resolve this by disabling this option. Go through with below link:
http://tivadj-tech.blogspot.in/2012/09/certificate-check-error-when-installing.html
I just tested this on Windows 10 and 8 PRO now, to get this right, follow these steps:
1) From your Start menu, locate your DDK's "x64 Checked Build Environment" i.e. the custom DOS build screen. Right-click, run-as administrator...
2) Compile your source with the Build tools etc.
3) Go into your compiled code, and then create your test-certificate (you don't need to purchase one just yet, use your self-signed one created with the line below):
makecert -r -pe -ss PrivateCertStore -n CN=newhex.com(Test) NewhexTest.cer
The above means your certificate is called "newhex.com(Test)" and the generated file is "NewhexTest.cer"
4) Create / Edit your .CDF file which contains items about what your CAT file's contents.
5) Create your CAT file by executing:
makecat -v MyCDF.CDF
This should generate an un-signed CAT file that includes all files specified by your CDF.
6) Sign your CAT file as follows:
Signtool sign /v /s PrivateCertStore /n newhex.com(test) /t http://timestamp.verisign.com/scripts/timestamp.dll MyDriverWhatever.cat
This should result in a CAT file that is signed, but don't just install it, because your Windows can't trust Newhex's cert since it's not in the keystore, to fix this do:
7) Add your certificate to your private Key Store, remember this step MUST be done by an administrators access, otherwise you will get an error about (Keystore not found etc):
certmgr.exe -add NewhexTest.cer -s -r localMachine root
This should add into your keystore, Once done, you can then:
8) Go into your device manager, and add your new driver, you would get a warning but will be accepted and installed without the need to reboot with a forced (Don't check cert type account).
I tried this already and it works on Windows 10 and Windows 8 pro versions.
Kind Regards
Heider Sati
You are supposed to use inf2cat, not makecat, because you have an INF file.
You should work on addressing those warnings from inf2cat by fixing your INF file. Here is my INF file that uses usbser.sys and doesn't cause any warnings: https://gist.github.com/3647208
I was able to fix my INF file thanks to the advice from chinzei in the first post of this thread: http://www.microchip.com/forums/m488342-print.aspx
If you continue to have trouble, please edit your question to include the source of your INF file, or at least a link to the source.
I encounter the same problem and was able to install my driver with a TEST certificate using the instructions provided here:
http://msdn.microsoft.com/en-us/windows/hardware/gg487328.aspx
After rebuilding my c++ project, I got this error message at my output box inside Visual Studio 2008.
1>SignTool Error: No certificates were found that met all the given criteria.
1>Project : error PRJ0019: A tool returned an error code from "Signing library..."
How to solve this?
update:
here is from my visual studio setting...
signtool sign /n "Against Intuition Oy" /t http://timestamp.verisign.com/scripts /timstamp.dll Release\WOT.dll
signtool cannot find a cerificate named "Against Intuition Oy" in your certificate store; do you have it?
Try running signtool from the command line, try some different options to see if it works out. Run 'signtool sign /?' to get information, or check msdn for additional info.
You can create certificates yourself:
makecert -r -pe -ss MyTempCert -n "CN=Against Intuition Oy" MyTempCert.cer
sign:
signtool sign /a /s MyTempCert /n "Against Intuition Oy" Release/WOT.dll
If you do not need signing, disable or delete the postbuild event in the project's setting (in release mode, your debug mode doesn't have it) and obviously you will not get errors anymore.
In my case, I had the same error only because my user account had no password.
Setting a password for the user account fixed the issue.