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...
Related
I was struggling with setting up public key authentication via SSH on a Windows Server 2012 R2 instance. I installed OpenSSH on the instance.
I made sure to have the public key on the instance in the ssh folder of the user and tried to SSH in from an instance with the private key. However, I kept being asked for the password.
Finally, I came across this blog which says to comment out the following lines
#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
in the C:\ProgramData\ssh\sshd_config file. After that, I was able to login with the public key.
My question is, why did that work? I've never seen any indication on any other blog that this needs to be done and I'm not sure what commenting those lines does.
This change is introduced in here:
Override default location for authorized_keys for administrators by manojampalam · Pull Request #369 · PowerShell/openssh-portable
And here is the tread discussing this change:
Is administrators_authorized_keys a security problem? · Issue #1324 · PowerShell/Win32-OpenSSH
These two lines redirect the authorized_keys to a path that requires elevated session to make change while you are logging in with a admin account. This is said to prevent an admin login in a non-elevated session, generate a key pair and append the pubkey to authorized_keys in his home path. And then ssh localhost to get a elevated session inside a non-elevated one, which could bypass the UAC. The author of the commit thinks this is a privilege escalation.
According to the discussion in that thread, this change didn't actually solve any concern, but rather introduced a bunch of new issues. The biggest one is that it breaks the pubkey authentication in non-English environment.
It introduces a localization issue and even more unexpected behavior.
The entry in the default sshd_config reads: Match Group administrators - but that is a localized group name that only applies
to english Windows installations. This means that this Match
statement only ever matches as intended on english Windows installs,
in any other locale the translated name of the S-1-5-32-544 group
will not match and the authorized_keys of administrative users will
continue to be in their respective userprofile paths - what a mess!
Source: issuecomment-749098394
This is the reason I searched for the same issue in midnight and came across your question. Just delete or comment out those two lines.
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 need to sign an enterprise Windows Store app I've developed ,so that users can sideload it into their devices.
I'm in the process of obtaining a code signing certificate from GoDaddy. A lot of the next steps are still hazy for me - any additional details will be appreciated.
What I've done so far
The application is tested, and I was able to deploy it on machines that have a developer license.
Purchased a code signing certificate from Daddy but didn't know what to do next (based on past experience I thought I needed to generate a key pair and a certificate signing request on my developer machine)
Called GoDaddy support who said I actually need a driver signing certificate rather than a code signing certificate. The cost was the same so they instantly switched my purchase.
It turns out there is an automatic process for generating a CSR on Windows, but you have to use Internet Explorer for that. Apparently, the cryptographic stuff is somehow handled transparently by Internet Explorer and the GoDaddy website. I would love to know more about what is actually going on there.
As part of the process you need to provide the legal name and official address / phone of the software publisher (my client in this case).
Once you submit the request, it has to be approved by GoDaddy (who should somehow verify that I am authorized by the publisher to sign code on its behalf).
Next steps
I assume GoDaddy will need to receive some documents from the publisher. I'd love to know how that process works and how long it takes.
Once the certificate is issued, I expect there will again be some easy way to install it on my development machine. Question: is there a way to move the keys and the certificate to another machine?
I also expect Visual Studio (I'm using 2012 Express edition for Windows 8) to be able to use the certificate when creating app packages. Will I need to do some special setup for that or will it be straightforward (part of the "Create app package" wizard) ?
Some of the details I've put on the certificate signing request will eventually be visible on the actual certificate (visible to the persons installing the application). Which ones?
After completing the process here are my own answers:
It turns out the GoDaddy support representative was wrong when
advising me to use a driver signing certificate. I needed a code signing certificate.
The certificate does not show the details of the contact person (which are included in the certificate signing request). You can see the certificate details before you submit the request (I missed it initially). In my case the details shown are the company name, city, state and country.
The documentation requirements depend on the company requesting the certificate (in some cases they may not need any documents at all). GoDaddy has very friendly support, so you should can the requirements from them. The process can take a few days to complete (but they may be able to help in doing it faster).
When using Internet Explorer both for the certificate request phase and installation phase, the process is seamless. I believe it uses Microsoft's Certificate Enrollment API (which is also described in this MSDN blog post)
As mentioned by JP Alioto, the process for using the certificate is described in the article "Signing an app package (Windows Store apps)". To use the new certificate in a specific project:
Open the projects .appxmanifest file
Go to the "Packaging" tab
Next to the publisher field, click "Choose Certificate"
In the dialog that pops up click "Configure Certificate" and select the drop down option "Pick from certificate store ..". The certificate should be available as one of the options.
To export a certificate, you can use the following process:
Run certmgr.msc
Locate the certificate
Right-click > All Tasks > Export to launch the certificate export wizard, which has an option to export the private key
Warning: the private key is supposed to be personal and you should protect it. It is probably OK if you copy it to another machine that you control (assuming nobody can snatch it in transit). Sharing it with someone else may be risky. I was not able to find information about how exactly the private key is used by Windows, but it may be a bad idea to have several people share a private key.
To import the certificate and private key from a PFX file, right click on the file in Windows Explorer, and elect "Install PFX". This will launch a straight-forward "Certificate Import Wizard".
Lots of stuff there. :) There are are few documents you need to read:
Deploying Metro style apps to businesses
How to Add and Remove Apps
Signing an app package (Windows Store apps)
Reading and understanding these documents will give you a better idea of what's going on. Are you sure the enterprise you're deploying for does not already have a trusted root certificate that they deploy to their desktop images? If they do, it may be easier to use that private key to sign the app. (The only reason a public certificate authority is recommended is that you will then not have to deploy the certificate to the target machines.)
You can move certificates (and private keys unfortunately) in the evil PFX format which is basically a PKCS #12 portable key file. But, be very careful how you move that file around. It contains both your public key and your encrypted private key.
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.
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).