I'm trying to setup SSO using OWin and Thinktecture Identity Server but I am not having any luck getting the SSL certificate to work. At least I think that's the problem. All works fine when I'm in visual studio, but if I try to use IIS on my machine it gives me the error "The remote certificate is invalid according to the validation procedure". I've also tried using IIS as the client treat the instance running in visual studio as the token authority but I still get the same error. Anyone have any ideas on what I'm doing wrong?
In my case I was just trying to work through the samples (for ID3v2) and getting the cert errors running locally. Since some samples even do self hosting via owin I'm not even sure where it's getting the certs for host side??
Anyway my fix was to copy the cert to the Trusted Root:
Windows => Start => run MMC.EXE
File=> "Add/Remove Snap-In..." => Certificates
Use Computer Account => Local computer => Finish => Ok
Go under Personal / Certificates
Right click "localhost", Select Copy
Paste to "Trusted Root Certificate Authorities"
Done. Enjoy.
After spending a lot of time for me the solution was pretty simple
I just opened the Certmgr.msc ---> deleted the localhost certificate from the Trusted Root certification authorities.
Then opened my solution (after I had run the identity sever)
clicked run the visual studio asked fro me if I want generate new certificate to iis express (ssl),
I had clicked yes and then it started to work properly:)
You need to add whatever certificate IIS is using to your Trusted Root Certification Authorities store on your local computer.
That can be caused by bad configuration on a previous certifications (sometimes can happen when you disagree to install a certification) :
Windows Start and open Certmgr.msc
Under Personnel/Certificats, find all localhost certificats and delete them
Same thing to do under Trusted Root Certification, and then close.
Start your application, you will get an exception.
Open the Package Manager Console and excute: dotnet dev-certs https --trust
Restart your application, normally you have a valid certificat now.
Adding certificate to Trusted People store should be enough according to readme file in examples provided by the authors.
In a production scenario it should be better because Root store is for CAs and when you add something there that authority is not only trusted, but any certificate signed by it is automatically trusted.
You can check this an further details from the microsoft reference. An extract of the 2 store short description:
Root: Certificate store for trusted root certification authorities (CAs).
TrustedPeople: Certificate store for directly trusted people and resources.
P.S: I tested it an it works. In my scenario I have IS on machine A and a set of web applications using IS on machine A and B. IIS certificate on machine B is different from the one used in A and by IS, but I just added it on machine B Trusted People store and the "certificate error" disappeard.
Some times it doesn't work though the above settings were done and you have given the URL as "https://localhost", instead give the URL as "https://MachineName".
i.e machine name should match certificate's "issue to" value
For .Net Core change TrustServerCertificate=False to TrustServerCertificate=True and that will solve your problem like I have it below.
"DataConnect": "Server=tcp:127.0.0.1,1433;Initial Catalog=dbName;Persist Security Info=False;User ID=username;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=True;Connection Timeout=30;"
I am trying to get our build server (TFS2010) to sign the assemblies for one of our projects.
I have manually imported the pfx (and associated 'chain' certificate) from verisign on the build machine, under/within the context of the build user account. I am using ResovleKeySource as part of the before build where I should be getting the ResolvedThumbprint as an output parameter.
The project file has the SignAssembly property set to true.
When i run this locally (ie build within VS2012), if I add a property to the proj file (ie CertificateThumbprint) with the thumbprint, on my local machine it finds the certificate in the store and signs the assembly.
The same thumbprint value is passed as a parameter to the build process, I can see it's there (using message statements) however, as noted, it never resolves.
Build user is local admin on that machine.
Has anyone encountered anything similar, and have suggestions on how to resolve the issue?
I am not getting errors from the build process (ie such as can't find certificate in store) - I get nothing. No errors, but no resolved thumbprint either.
Ok, so it looks like there may have been a funky (unprinted) character in the thumbprint that was passed as a parameter from TFS to build. I had another developer look at the build definition, got them to modify the thumbprint parm value (yes, the ONLY change made) and, voila, the build starts signing like a champ....
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.
We are upgrading the server from Windows 2003 to 2008. As part of the process, I need to configure a port with a SSL certificate. When I ran the following command:
netsh http add sslcert ipport=1.2.3.4:8000 certhash=certificatehash appid={someGUID}
I got the following error:
SSL Certificate add failed, Error:
1312 A specified logon session does
not exist. It may already have been
terminated.
When running the command prompt with an administrator does not resolve the issue. Notice that I did not run into this issue on Windows 2003 (using httpcfg) and that things work well there.
Has anyone encountered this issue? Thanks.
the 1312 shows up at several occasions. aside from typos on the commandline, the other most common are:
- the certificate is not in your certificate store at all (check with MMC and 'certificates' snap-in)
- the certificate is in the wrong store: it should be in the store of 'local computer' not 'local user' (remember to choose proper account when activating the snapin inside the MMC)
- the certificate doesnt contain a Private Key (open the certificate and check whether it contains only public, or both keys)
I've spent over 1.5 hours before I found out that I've had generated a certificate succesfully, but misplaced some switches and it got written to a file without the private key:)
Are you running from an elevated command prompt (not just as an admin)?. There's an open source GUI tool that drives the HTTP config APIs directly- I use it on 2008 R2 with no trouble (it auto-requests elevation via UAC). I've had mixed results with netsh/httpcfg. This one always works for me (and it behaves the same everywhere).
I purchased an authenticode certificate from a well known provider.
Now I want to strong name an assembly and later on digitally sign it.
This is what I've done so far:
Extracted public key from pfx by running sn.exe -p keypair.pfx key.snk
Checked both "Sign the assembly" and "Delay sign only" checkboxes on project properties signing tab
Provided key.snk as keyfile to sign with
Extracted public key token by running sn.exe -tP key.snk
Disabled strong name verification on my devbox by running sn -Vr *,
The idea is to disable delay signing on the team build and provide the keypair.pfx file there. This way, I can fully sign the assembly on the team build server that has restricted access while not providing the private key on the dev boxes for security reasons.
However, when trying to build the assembly locally, I get the following error:
Cryptographic failure while signing
assembly '.dll' – 'Bad
Version of Provider'
Does anyone have a solution for this?
I got a reply from Comodo:
There's problem with VS2005/2008 and
authenticode certificates. (Microsoft
level) They can't be used for Strong
Named Assemblies. You have to create
your own private key to do the strong
name signing.