Please note that this issue is only applicable for Windows Server 2008 SP2
I have developed one windows application. Prior distributing it I have signed and time stamped it using SHA1 and SHA256. This application is formed with multiple DLLs. I am signing each DLL during build process. I have used certificate from VeriSign. At the time of execution, when application is launched it verify the signature and time stamp of each DLL to ensure integrity using WinVerifyTrust API. I am getting "E_CERT_EXPIRED - Signer's Certificate was expired" error during validation.
Also, I am not able to see the time stamping details in property page of the executable. Please see below -
Now, that certificate is expired but according to this SO article What happens when a code signing certificate expires?. The executable should run perfectly without any problem.
I have also checked for this KB suspecting the cause but fix related to this KB is already applied. Can anybody share more light on this?
You cannot sign with expired certificate, it not works (you see results yourself).
What you can do is to sign with valid certificate and then signed application will not expire because of valid timestamp at the time of signing.
I'm trying to use PeopleCode to get a file from a remote FTP server that uses SSL. The GetAttachment command returns error code 8, which indicates a problem connecting or authenticating with the "destination server" (which I'm assuming means "remote server"). I don't think the problem is in my code itself, although I'm not discounting that, but rather in the URL configuration and the security certificate.
First, my PeopleCode is:
&returnCode = GetAttachment(URL.MY_FTP_URL, &fileName, &destinationPath);
If &returnCode = %Attachment_Success Then
[...]
Else
MessageBox(0, "", 0, 0, "Fail: " | &returnCode)
End-If;
I've created the URL definition via PeopleTools > Utilities > Administration > URLs. The URL is pretty straight forward. The URLID is "ftps://[remote server]/". I know this connection requires active mode and SSL, so I've added the properties (in addition to username and password) ACTIVEMODE = Y, and SSLUSAGELEVEL = 3.
Now, here is where I think the problem is. By adding the SSLUSAGELEVEL property, I also need to add the CERTALIAS property and (presumably) set it to the name of the SSL certificate. So I got the certificate, uploaded it and created the definition. I went back to the URL definition, added the CERTALIAS property, but the prompt box for the valid values is empty.
I think my problem now is that I need to perform some other step to get the certificate I created to show up in the CERTALIAS prompt. Is my approach generally in the right direction? Or am I missing something else entirely?
Thanks,
First, confirm that it is working at the operating system level.
I have noticed that GetAttachment does not always copy over the ssl certificate with the proper file system permissions, in Oracle linux, to the app server working directory and because of the incorrect file permissions, the destination server will refuse the connection.
I had to create the key file with the correct file permissions and hardcode the path to this key file, with the correct file permissions, in the URL entry.
I'm trying to sign a Windows 8 appx package with a pfx file I have. I'm using a command like so:
signtool.exe sign /fd sha256 /f "key.pfx" "app.appx"
And from this, I get:
SignTool Error: No certificates were found that met all the given criteria.
What "criteria" am I not meeting? This is only for testing so these are self-signed certificates. I've tried importing the key and then signing it, but it always results in the same error. How do I fix this?
When getting this error through Visual Studio it was because there was a signing certificate setup to match the computer it was originally developed on.
You can check this by going to the project properties > signing tab and checking the certificate details.
You can uncheck "Sign the ClickOnce manifests" to disable signing.
If you don't want to turn this option off you will have to install the certificate.
Try with /debug.1,2 As in :
signtool sign /debug /f mypfxfile.pfx /p <password> (mydllexectuable).exe
It will help you find out what is going on. You should get output like this:
The following certificates were considered:
Issued to: <issuer>
Issued by: <certificate authority> Class 2 Primary Intermediate Server CA
Expires: Sun Mar 01 14:18:23 2015
SHA1 hash: DD0000000000000000000000000000000000D93E
Issued to: <certificate authority> Certification Authority
Issued by: <certificate authority> Certification Authority
Expires: Wed Sep 17 12:46:36 2036
SHA1 hash: 3E0000000000000000000000000000000000000F
After EKU filter, 2 certs were left.
After expiry filter, 2 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.
You can see what filter is causing your certificate to not work, or if no certificates were considered.
I changed the hashes and other info, but you should get the idea.
1 Please note: signtool is particular about where the /debug option is placed. It needs to go after the sign statement.
2 Also note: the /debug option only works with some versions of signtool. The WDK version has the option, whereas the Windows SDK version does not.
I got the same problem in my console application development and as a quick workaround,
go to project properties then,
click on signing tab and uncheck "Sign the ClickOnce Manifest".
Image Description:
FYI You can also see this less one minute video solution. The above picture is taken form the video.
Please always check your certificate expiry date first because most of the certificates have an expiry date. In my case certificate has expired and I was trying to build project.
If you do not have to sign the app, right click on your project
Project Properties -> Signing -> uncheck "Sign the ClickOnce Manifest"
Also as this MS article suggests,
If you are using Visual Studio 2008 and are targeting .NET 3.5 and using automatic updates, you can just change the certificate and deploy a new version,
In my case I have the wrong type of certificate that I am trying to associate. I had "Server Authentication" rather than "Code signing".
You should be able to see this in Certificate snap in the Intended Purpose section. After that, it just work fine.
Got the same issue, turned out that the private key to the certificate had no permission.
To fix - open the certifacte management, find your certificate, right click -> Manage Private Keys and then in security on top be sure that your user is added and given permissions, that fixed it for me.
In case anyone else runs into this: My problem ended up being that I needed to run the command prompt as administrator before using the signtool.exe app. Then everything works wonderfully.
just uncheck the 'Sign the click once manifests' from the signing tab in project properties,it will remove the error and you can create a new one as from there.
I had this problem and I'm not entirely sure which step below made it work, but hope this helps somebody else...this is what I did:
Install the downloaded certificate (.crt) into certificates (I put it into “personal” store) - right click on .crt file and click Install Certificate.
Run certmgr.msc and export the certificate (found in whichever store you used in the 1st step) as a pfx file including private key and extended properties
Use the exported .pfx file when signing your project
Example signtool: signtool sign /f "c:\mycert.pfx" /p mypassword /d "description" /t http://timestamp.verisign.com/scripts/timstamp.dll $(TargetPath)
where the password is the same as provided during Export
I solved this by using the /sm flag to specify to look in the machine store instead of the default, which is My (Local User) store. Also, it can help to turn on debug for signtool by using /debug.
I'm having the same problem, reading some answers (posted here), I saw my certificate expired.
Just create a new one from my start project. Then at certificates manager deleted the expired certificate.
Now everything compiles fine.
The criteria include account name (whose private key it is associated with), domain, company, expiration date, intended purposes, among other things.
There are many different possible reasons for this error to occur, some have been listed already. Here is another tip: When importing a certificate, be sure you work with the original file received from the certificate authority (CA), or else some of the properties might be lost.
Example: recently I tried to import a certificate exported from a different account on the same machine. The certificate became visible to my account but was not associated with my account, and as a result signtool refused to recognize it without explicitly providing the file name and a password. Which, when done as part of the build process and written out explicitly in a batch file or source file, may not be sufficiently secure. (Importing the original CA-issued certificate solved it.)
I had the same "After Private Key filter, 0 certs were left" message and spent too much of my life trying to figure out what the message meant.
The problem was that I had installed the certificate incorrectly in the Windows Certificate store so there was no private key associated with the code signing certificate.
What I should have done was this:
Using either Firefox or Internet Explorer, submit the
request to the issuer. This generates a PRIVATE KEY which is stored silently by the browser (a dialog appears for a fraction of a second in Firefox). Note that other browsers may not work: your life is too short to find out if they do.
Submit the request, jump through the issuer's validation hoops and loops, sacrifice a goat, pray to the gods, submit a signed statement from your great grandparents, etc.
Download the certificate (.crt) and import it into the same browser. The browser now has both the private key and the certificate.
Export the certificate from the browser as a Personal Information Exchange (.p12) file. You will be asked to supply a password to protect this file.
Keep a backup copy of the .p12 file.
Run the Certificate Manager (certmgr.msc), right click on the Personal certificate store, select All Tasks/Import... and import the .p12 file into Windows. You will be asked for the password you used to protect the file. At this point, depending upon your security requirements, you can mark the key as exportable so you can restore a copy from the Windows store. You can also mark that a password is required before use if you want to break batch scripts.
Run signtool successfully, breathe a sigh of relief, and ponder how much of your life you have wasted due to bad error messages and poor or missing documentation.
My problem ended up being that I did not understand the signtool options. I had provided the /n option with something that did not match my certificate. When I removed that it stopped complaining.
I have had this issue too, tried a lot. Used SDK as well as Visual Studio signing, but everywhere I got "No certificates were found that met all the given criteria".
Solution:
Be aware that, if "after private key filter": '0 left' shows up with option signtool sign /debug..., the cause is your PC doesn't has the CA itself in the store. To solve this, install the CA first (in my case a .crt file), then run the sign again. It should work right now!
Signtool only can be used with a CA which is requested ánd owned by the same PC.
I had a similar problem my computer name had change and the certificate had expired. I was able to resolve this issue by creating a new test certificate.
In Visual Studio, right click on project in solution explorer. Select properties. Select Signing in properties window. Click "Create Test Certificate....". Enter password information for test certificate and click ok.
With /debug, when you get this message "After Private Key filter, 0 certs were left.", one reason could be that the pfx file doesn't have the private key.
When you export the installed certificate to pfx file ensure to enable the check box to also include the private key.
Go to project properties and uncheck all fields from the Firm before init the compilation
The digicert Token I use, must be recognized as "Microsoft Usbccid-Smartcard-Leser(WUDF)".
In case not, I get this error message 'No certificates were found that met all given criteria ...'.
That kept me searching in SignTool options and the properties of the certificates quite long with no effort at all. So I hope it helps someone :-)
I got this error when using Git Bash.
Using PowerShell succeeded.
If it helps anyone.
I am trying to ignore the certificate warning on remote desktop connection - the one in the image:
So far I have found that when I check the "don't ask again" checkbox it is generating registry key over here:
HKCU:\Software\Microsoft\Terminal Server Client\Servers
A new record is generated with the name of the server and key name CertHash that contains a value that is specific for a machine. The key is the same for a machine - if I delete it and check the checkbox the same value is again generated. There is a new value in case I recreate the virtual machine so I think it is something machine specific.
Can someone tell me how is this hash generated so I can populate the key from command line? Adding certificate is not an option and the machines will be frequently regenerated so I need an option to ignore this automatically as I need to connect a user to the machine and run some programs in it.
I know this is an old question. But this may help someone who is looking for the same solution.
Method 1
You may over ride the certificate check for ALL RDP connections (use it at your own risk)
Just add a new registry key as below.
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v "AuthenticationLevelOverride" /t "REG_DWORD" /d 0 /f
Method 2
Considering if you have admin rights on the remote machine, you could actually get the crethash value from the remote machine using the below wmic command. So you could make a small batch file to get this value before you launch the mstsc and add this value in registry. I haven't included the complete batch file but thats the idea.
wmic /node:Testserver /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting get SSLCertificateSHA1Hash
See this link.
Run Microsoft Management Console (mmc) and add the Certificates snap-in if you don't already have it for the computer you would like to connect to. In the Certificates, find the Remote Desktop folder, and open the certificate in that folder. On the Details tab, scroll down to find the Thumbprint value - this is the value you should copy to the registry.
I'm currently migrating a Jenkins server and I'm having trouble getting some projects to build. The problem projects are failing with this error (which I edited a little for readability):
error MSB3326: Cannot import the following key file: . The key file may be
password protected. To correct this, try to import the certificate again or
import the certificate manually into the current user's personal certificate
store.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1970,9):
error MSB3321: Importing key file "MyCertificate-LP.pfx" was canceled.
[D:\Jenkins\jobs\keyword_addin\workspace\KeywordOptimization\
KeywordOptimization.AddIn\KeywordOptimization.AddIn.csproj]
The thing is, I've gone and added this certificate to the store of the local system account, which I believe is what Jenkins is running under, and I'm still getting this same error. Furthermore, what I execute
sn -i MyCertificate-LP.pfx personal
and enter in the password on a command prompt running under the System account. I get
Failed to install keypair -- Object already exists
What's even more confusing is that when I run MSBuild from the command line as the Administrative user I'm signed in as, the build succeeds.
I'm not really sure how to trouble shoot this further. If I can't figure out the certificate situation with the System account, is there a way to tell Jenkins to run MSBuild as a user other than 'System'?