After signing my Application using Test certificate (pfx) with signtool when I try to verify using signtool verify I am getting below error code
SignTool Error: WinVerifyTrust returned error: 0x80096019
A certificate's basic constraint extension has not been observed.
I have Tried to other exe with the same cert still the same Issue?
I have tried different certificates with the same exe still the same Issue?
I have searched on the Internet I couldn't find a source or Link. Any Help would be much appreciated?
You maybe use a CA certificate to sign. A CA certificate should issue a Code Signing certificate so you need a second certificate to sign your executable (Basic Constraints = LIMITED to 0 or false) that is then used to sign the executable.
This second code signing certificate is signed with the CA certificates private key.
Related
I have valid COMODO certificate which I use to sign DLLs. I now need to sign applet.jar and for this I used this command:
jarsigner "PATH_TO\my.jar" -storetype pkcs12 -keystore "PATH_TO\cert.pfx" 1 -tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp
As result I get warning:
The signer's certificate chain is not validated.
And my applet is considered as self-signed. I found this solution: The signer’s certificate chain is not validated and the same here, but now when I try to sign jar with exported certificate I get this error:
jarsigner error: java.lang.RuntimeException: keystore load: Integrity check failed: java.security.NoSuchAlgorithmException: Algorithm HmacPBESHA256 not available
I tried to add this to command line -sigalg SHA256withRSA -digestalg SHA256 but nothing changed.
Can anybody help with this issue? Thanks in advance.
I solved my problem by solution from original question, BUT key point is that you can NOT use Windows 10 for this trick, I used Windows 7 and it works just fine.
Why? no idea...
I have a p12 file, 'test.p12,' that has a certificate, the CA cert (self-signed), and private key for the certificate. The p12 file is generated using the BouncyCastle's C# API.
When trying to import the certificate by using 'CertUtil', i.e., 'CertUtil -f -p password -importpfx test.p12,' CertUtil generates the following error:
CertUtil: -importPFX command FAILED: 0x80090016 (-2146893802 NTE_BAD_KEYSET)
CertUtil: Keyset does not exist
Any clues as to what may be wrong? (I'm using Windows 10)
Using openssl, I can see that 'test.p12' does include the certificate, CA cert, and private key. The certificate is using an EC keypair, but I doubt that's a problem since I have a reference p12 file that uses the same algorithm and is imported by CertUtil without problem. Unfortunately, I have no detail on how the reference file is generated.
In my google searches, many seem to suggest that this may be a permission problem, but I doubt that's the case as I'm running the CertUtil as the Administrator.
When importing the same file using 'MMC' with the certificate snap-ins, the certificate is "successfully" imported if I force the MMC to store it in a specific store, e.g., Personal; otherwise, it prompts to select a Smart Card for the certificate. Could this be a related problem?
Thanks,
--Hyong
I'm trying to sign my app in VS2012 but I'm receiving "Cannot find the certificate and private key for decryption" error.
What I do:
I received my certificate by Comodo CA Limited in Google Chrome.
Exported the certificate to a file with "Include all certificates" and "Export private key" options.
In VS2012, Signing tab I browse to the certificate file and fill in the password. The "Cannot find..." error appear.
I also tried all steps in this tutorial: Visual Studio error 'Cannot find... in Comodo Knowledge Base, but no success.
The same key works fine when signing with the Comodo kSign tool and also when using signtool.exe
....
The most common problem arises when using a .pfx file that contains
chaining information. You can remove chaining information from the key
file by running the Certificate Manager snap-in (Certmgr.msc),
importing the pfx file into the personal certificate store, and then
exporting it without including the certificate chain information.
Importing the certificate in MMC and exporting again doesn't help
...
I tried it on other machine, but the same problem.
Any ideas?
https://msdn.microsoft.com/en-us/library/aa730868%28vs.80%29.aspx#rsvssign_topic3
The .pfx file cannot include certificate chaining information. (If the .pfx file does include this information, the following import error will occur: "Cannot find the certificate and private key for decryption.")
Just do not set "Include all certificates" while exporting the *.pfx file
I have a c# program and part of it creates a self-signed certificate.
The problem is when i try to import the certificate in MMC it says "This certificate has an invalid digital signature."
And when i try to add this certificate through command prompt using netsh http add it says:
SSL Certificate add failed, Error: 1312 A specified logon session does not exist. It may already have been terminated.
I've tried all suggestions from other questions similar to this but to no luck.
I've also tried downloading Hotfix from Microsoft but it didnt work.
By the way, my machine is running in Windows7-64bit.
I ran into an answer here The basic issue is that DC authority cert creators get sloppy and create multiple certs for the same DC cert authority. I had my self-signed cert created using latest and grates DC cert authority certificate. I had to export and install both root cert and a self signed cert on my destination machine for it to recognize self signed cert used on the server. But the root cert I exported was a cert with the same name but different dates. Once I located the proper root cert and installed it on my destination computer everything worked flawlessly.
In my case it was due to an old self signed certificate with a small key length.
I found the solution here - https://security.stackexchange.com/a/82606/26742 to reduce the security (only in my dev environment)
certutil -setreg chain\minRSAPubKeyBitLength 512
How can i include the entire certification path when signing code using signtool?
Older versions of signtool would include the entire certification path in a digital signature. As it is now if i sign an executable with signtool:
signtool.exe" sign /v /f avatar.pfx -t "http://timestamp.verisign.com/scripts/timstamp.dll" app.exe
the signature is not valid:
This is because there is no certification path:
Binaries signed with the older version of signtool worked fine:
How do i tell signcode to include the entire certification path when signing?
What is the proper way to sign a binary?
Update: SignTool version 6.1.7600.16385:
See also
How can I sign an ActiveX control with a code signing certificate and be a verified publisher?
Signing WinForms ClickOnce app with Certificate Chain
ClickOnce: Certificate cannot be validated
Use /ac and pass the filename of the .cer in which your certificate is rooted (for Verisign it was called MSCV-VSClass3.cer last time I checked when signing kernel code or other special code).
signtool.exe sign /v /f "Avatar.pfx"
/ac "Thawte Code Signing CA - G2.cer"
-t "http://timestamp.verisign.com/scripts/timstamp.dll" app.exe
This should be given by your CA. Usually MS offers bundles for the various CAs it accepts within Windows.
See:
Windows root certificate program members 🕗
Cross-Certificates for Kernel Mode Code Signing 🕗
Either way, to my knowledge this is only required for kernel code and very specific other things (e.g. Windows Security Center).
If you use Thawte then download their primaryca.cer.
Download to file primaryca.cer and sign your file with:
signtool sign /f certificate.pfx /p PASSWORD /ac primaryca.cer APP.exe.
Should work.
The documentation for authenticode signing
Windows Authenticode Portable Executable Signature Format (.docx 🕗)
says that the PKCS #7 SignedData structure...
...contains the signer certificate and any intermediate certificates, but typically does not contain the root certificate.
However, as I discovered in a bit of a 'DOH!' moment, signtool.exe must be able to find the certificates to include them.
The leaf certificate is provided on the command line. But the identification of the remaining certificates up the chain does not include where to find the certificates. signtool does check the system certificate store, so if they are found there, they are added to the binary. If they are not found, signtool only puts the leaf certificate into the signed binary.
Note that if the intermediate certificates are not in the signed binary, but are in the system certificate store of the system checking the signature, the binary will still pass verification, because the chain can be resolved.
Also note that the exclusion of the root from the signed binary makes sense, given that the root must independently be on the system checking the signature for it to be trusted, so it would be ignored anyway. (The only real benefit to including the root in the binary would be if someone wanted to import the root cert manually, which is almost always a very bad idea.)