I am developing a WCF service on my local computer using Visual Studios built in ASP.NET development sever and I'm having issues creating and using temporary Certificates.
I have created a cert call TempCA and added it to the Trusted Root Certificate folder and I have created another called SignedByCA which has been added to the personal folder.
The service config file has been set up to use SignedByCA but when I run the service I get the following error.
The certificate 'CN=SignedByCA' must have a private key that is capable of key exchange. The process must have access rights for the private key.
I have tried using WinHttpCertCfg.exe to give other users access to the key but I have since found out that WinHttpCertCfg.exe has be deprecated in windows Vista.
Has anyone had this issue before in a similar circumstance??
Try certmgr. But I suppose you used the makecert to generate the certificate, you don't need to use WinHttpCertCfg to install it. It should be installed automatically.
Also, if you are hosting the service in IIS, the private key is normally generated in
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
You can try granting read-only security of the MachineKeys for the user "NETWORK SERVICE" (user for IIS6).
Related
I am trying to run certutil -repairstore and keep getting prompted for a smart card. This is a VM on AWS and a smart card is not an option. Any thoughts on how to bypass the smart card and get the repair to complete are appreciated
One of the other answers touched on it, but I wanted to add some context/detail as well as I spent a lot of time searching for the root of this problem. Killing the smart card-related services did not work, nor did disabling the related policy with gpedit.
When you run certutil with the -repairstore option, Windows runs through its list of CSPs (Configuration Service Providers), one of which is the "Microsoft Smart Card Key Storage Provider" - that's the one that causes the prompt to enter your smart card. As the above answer stated, the most likely cause is that you are attempting to install a certificate file (.crt, .cer, .pem, etc.) that does not have a corresponding key on the VM, so Windows is cycling through the various CSPs looking for a valid key but cannot find one. There are two possible solutions to this problem:
You should generate your CSR (Certificate Signing Request) through IIS > Server Certificates > Create Certificate Request. This will ensure that the key is generated locally and the appropriate key store is aware of it. Use that CSR to get your certificate from GoDaddy or whoever your provider is, then you should be able to go to IIS > Server Certificates > Complete Certificate Request to install the certificate and avoid certutil altogether.
If you still can't get it to work and are sure the key was generated locally, the -csp option for certutil will allow you to specify which CSP to use when validating the certificate thereby eliminating the need for Windows to try the smart card CSP. You can get the installed CSPs on your system by running certutil -csplist - the "Provider Name" value is what you pass to certutil. For example, certutil -csp "Microsoft Software Key Storage Provider" -repairstore ... would force certutil to validate against the Microsoft Software Key Storage Provider. Make sure you use quotes since there are spaces in the names.
Make sure you make the original certificate request on the same windows server where the domain is hosted. Then complete the request with the p7b provided by the ssl supplier and you won't have any problems.
This question might be a bit old but I came across this error with another cause:
I have mutliple servers trying to import the certificate.
However, the cert request was generated from one server. In that case, I imported to the original server which create the request and export everything from the mmc (including private key) and re-import the pfx file to the over servers.
Try to add -silent to the command
I am trying to get the signing working with TFS 2010. I already imported the .pfx File in the Personal Store for the Build Computer. I read somewhere i have to do this for the account the build service is running under. But i don't know how i can do this for "NetworkService", which is the account under which my build service is running.
The error message i am getting of MSBuild:
Unable to find manifest signing certificate in the certificate store.
I read somewhere i have to use the sn -i mycert.pfx VS_XXX but i have no idea where to get the VS_XXX from?
The only working solution for me seems to use another user account for this. In my case I needed a valid domain user. Because the user needs to have the correct rights for the team foundation server.
I logged in with this user on the build machine and added the certificate to my certificates (you should be able to do this by double clicking it).
I am having a strange problem which I've googled and googled with no result. I'm attempting to setup a certificate for a wcf service application on windows server 2008 R2. I've imported the certificate into the localmachine personal store, and I'm getting the dreaded
"Keyset does not exist...the certificate ... must have a private key that is capable of key exchange. The process must have access rights for the private keys."
I have tried to set the permissions on the private key, using the "Manage private keys" option in mmc, also tried setting the permissions on the private key file manually that is located in C:\programdata\microsoft\crypto\rsa\machinekeys. I verified I'm modifying the right file by using the findprivatekeys tool, and also tried using the WSE X.509 Certificate tool. For sanitys sake, I even gave read access to "Everyone" on the file, still doesn't work.
Is there something I'm missing here? I'm using IIS7 and I normally give access to the file for the IIS_IUSRS group. All of this has worked fine in other testing on VMs. I've even used the exact same certificate on other machines, and they work there...
I'm lost...The one thing I've noticed is that if I edit the permissions in the 'manage private keys' dialog, the security settings changes don't reflect when I look at the permissions for the file, and vice versa. Where else could the file be? Regardless, I gave max permissions from both places with no luck.
Not sure what was going on here, but over the course of testing, the permissions on the MachineKeys folder was drastically modified - so I removed permissions for all the users listed there except the Administrators group, deleted the problem certificate (through mmc) and re-imported it again. Then, I added IIS_IUSRS read and execute permission only for that private key, and I seem to be back up.
On a related note, I was using aspnet_regiis -pi to import a key pair for something else, which was failing with "Safe handle was closed." Fixing the permissions on the MachineKeys folder fixed that as well...
Having trouble with ClickOnce manifests and our build server.
We have a .p12 code signing certificate (which is the same as a .pfx). I can assign this certificate on a developer machine in:
Visual Studio->Project->Properties->Signing->Select from file, then
enter the password for the certificate.
Everything builds/publishes fine locally.
However when checking in all files to our TFS build server the automatic build generates this error:
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.
Is there a way to pass in the password to the build definition so that the built assembly is signed?
Also each developer who does a 'get latest' currently needs to re-sign the assembly with the correct password each time, is there a better way?
Note:
The build server does not have Visual Studio.
I have tried manually importing the certificate, under the account that the build runs on, to the personal certificates folder.
This is what fixed my problem:
1 ) Logon as the TFS build controller account and install the certificates manually there.
2) With some older certificates there can be a problem with the root authorisation (chaining), in this case download the root certificate from your certificate issuer, and possibly an intermediate certificate.
3) Make sure the computer/virtual machine that is running the service "Visual Studio Team Foundation Build Service Host" is running under an account that has the certificates installed. In our case this is the same as the build controller account.
I have a WCF project in Visual Studio that I need to deploy to a client's test server. I was on the brink of declaring "Mission Accomplished" when I realized that I have no idea how to take my project from Visual Studio 2010 to something that I can deploy on the client's server.
My gist of this problem is that we use a makefile to do building and packaging when deploying to the client. This means that I need a command-line executable to do whatever it is that I need to do to deploy my WCF service. I did discover right-clicking the project and selecting "Build Deployment Package", but since I need to execute via command-line, I don't think this is going to help much.
The bonus second part of this problem is that, once I get the packaged file the client's server, I'm not sure what to do with it. Now, if I knew what to expect from the packaged deployment file, I might have a better idea, but until then, it's all just speculation.
OK, here is what I came up with.
Packaging
First, the packaging. Use msbuild. Something like this (apparently you need to use a v4 or better version of .NET for it to succeed):
C:/Windows/Microsoft.NET/Framework/v4.0.30319/msbuild.exe {project_file} /t:package /target:Build /p:PlatformTarget=x86;
Fairly easy, right?
Deployment
Now, the bonus part of the question, the deployment. This consists of the easy part and the hard part. The easy part was getting the .zip file created with msbuild.exe added into IIS. I found 2 possibilities.
Commandline
The first is the command-line, which gave me issues (something about being unable to cast 'Microsoft.Web.Deployment.DeploymentProviderOptions' to type 'Microsoft.Web.Deployment.DeploymentProviderOptions' --- I KNOW, RIGHT?). Anyway, this is the command-line I used. It may help someone, or it may not. Again, I had issues with it.
c:\inetpub\wwwroot>"c:\Program Files\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -presync:runCommand="md c:\inetpub\wwwroot\{MyWCFCodeDest} & c:\windows\system32\inetsrv\appcmd add site /name:{MyWCFCodeDest} /id:22 bindings:http/*:54095: /physicalPath:c:\inetpub\wwwroot\{MyWCFCodeDest}" -source:package={ZipFileFromMSBuild.exe} -dest:auto -setParam:"IIS Web Application Name"="{MyIISName}"
UI
OK, so I decided I would be happy with using the second way. It's by far the easiest if you don't care about automation. Open up IIS Manager, right-click the computer OR the website (depending on whether you want it as its own website or an application in an existing website), Deploy, Import, and follow the wizard to the end.
Errors in Deployment
And now where I spent most of my time. I hit my newly deployed .svc file and get an error. This error involves the certificate I was using. Now, maybe not all deployments will have to worry about this, but mine did. The error was lengthy, something about "keyset does not exist" and "cannot be activated due to an exception during compilation" and "may not have a private key that is capable of key exchange or the process may not have access rights for the private key". I tried a bunch of stuff, including using mmc to re-import certs and makecert to recreate both my CA and my personal cert. None of that was the problem for me (ymmv). Finally, I focused on user rights. I found that if I gave the Everyone user permission to the private key for the cert (the cert needs to have a private key), everything worked. Obviously not a solution I want for a client, so I hunted down the correct user to give rights to. Surprisingly, this took a while. Various websites had me adding Network Service, ASPNET, current user, the user specified in machine.config (which is in the .NET directory somewhere), IIS_{MachineName}... none of these worked. The one I had to add was IIS_IUSRS.
So, a handful of caviats that may help your sanity when you scream at your monitor that this isn't working for you, despite following all the directions. Because apparently IIS changes far too much over time and this stuff does matter:
Windows 7 Ultimate sp1
IIS 7.5.7600.16385
Useful Related Stuff
Also, some commandline tools you may be interested in:
-winhttpcertcfg.exe -l -c LOCAL_MACHINE\My -s "{cert_name}" -- lists the users authorized to access the cert's private key (you can also do it the old fashioned way through file properties); I tried downloading winhttpcertcfg.exe, but it was part of a Windows 2003 package that gives warnings about not being compatible (not sure if it came from my attempt to install that file or if it now comes with something I already had installed)
-winhttpcertcfg.exe -g -c LOCALHOST\My -s "{cert_name}" -a IIS_IUSRS -- adds IIS_IUSRS to the permissions for the cert's private key
-findprivatekey.exe My LocalMachine -n "{cert_name}" -- Finds the private key file for the specified cert; for some reason, this is a tool that you have to build in Dev Studio on your own (found in some WCF examples downloaded from Microsoft)
-cacls.exe {private_key_file_for_cert} /E /G "IIS_IUSRS" -- another way to add a user to the private key's permissions
-mmc -- launchs a manager for installed certificate
-makecert -n "CN={CertificateAuthorityName}" -r -sv {CertificateAuthorityName}.pvk {CertificateAuthorityName}.cer -- create a certificate authority cert
-makecert -sk {SignedCertName} -iv {CertificateAuthorityName}.pvk -n "CN={SignedCertName}" -ic {CertificateAuthorityName}.cer {SignedCertName}.cer -sr localmachine -ss My -- create a certificate signed by a certificate authority
One last thing: if you want to import your certs using mmc, you need to launch mmc, File->Add/Remove Snapin. Add the Certificates snapin. Import the certificate authority to the Trusted Root Certification Authorities and the certificate signed by the certificate authority to Personal.
Hopefully you have enjoyed your ride here. Please wait for the browser to come to a complete stop before exiting, and please remember to take any personal items with you.
Additional Discoveries
When it came time to deploy everything to a test server (rather than my development machine), I didn't expect all the hassles that I encountered. I'm documenting these here, again, in an effort to help some other poor, lost soul (or myself at a later date).
-This one should have bee obvious: FindPrivateKey.exe wasn't on the server. I had to jump through some hoops to get it there. ymmv.
-Only the client 4.0 version of .NET had been installed on the server. By the time I discovered this AND realized it was a problem, a few hours had passed. Discovery of the installed .NET versions came courtesy of netfx_setupverifier, which I got from one of Microsoft's websites. The client version doesn't include all the WCF stuff.
-IIS needed some additional settings (files found in the .NET Framework version directory, run from the commandline):
aspnet_regiis.exe -i -enable
ServiceModelReg.exe -r
-cacls.exe informed me that it was deprecated and that I should use icacls.exe. The commandline for icacls is something like:
icacls.exe {private_key_file_for_cert} /GRANT "IIS_IUSRS":R (note, didn't exactly work for me, but you can always just go to the {private_key_file_for_cert} file, probably in ProgramData\Microsoft\Crypto\RSA\MachineKeys, and give permissions via Explorer - right-click - properties)
-You may need to add a handler mapping for the WCF. I highly recommend having it running under an Application Pool that is .NET v4.0.