WCF Error : 'It is likely that certificate 'my cert' may not have a private key that is capable of key exchange

Question

I have a WCF service I'm trying to host on our production web server (IIS6). I've set the web up and tied our cert to the web. When I try to browse to the service url, I receive the following error in the event log :

The exception message is: It is likely that certificate 'CN=.mydomain, OU=Secure Link SSL Wildcard, OU=I.T., C=US' may not have a private key that is capable of key exchange or the process may not have access rights for the private key. Please see inner exception for detail.. ---> System.ArgumentException: It is likely that certificate 'CN=.mydomain.com, OU=Secure Link SSL Wildcard, OU=I.T., O=mydomain, C=US' may not have a private key that is capable of key exchange or the process may not have access rights for the private key. Please see inner exception for detail. ---> System.Security.Cryptography.CryptographicException: The handle is invalid.

I've confirmed ASP.Net 1.1, 2, and 4 are all set to 'Allow' in 'Web Service Extensions'. I've also confirmed the cert is set up in iis and it shows 'You have a private key that corresponds to this certificate'. Also, Execute Permissions are set to 'Script and Executables'.

Epiphysis

Answer 1

I had this problem, and it turned out that the account the service was running under did not have permissions to access the certificate's private key.

Here are the steps I used to solve it:

• Start the Cetificate manager. Do this by running MMC, activate [File]-[Add/Remove Snap-in...], then add "Certificates", selecting "Computer Account" and "Local Computer" in the ensuing wizard dialogs.
• In the certificate manager, right-click on the relevant certificate and activate [All Tasks]-[Manage Private Keys]
• This gives you a permissions window. Click Add
• Add the account name or group that this service runs under.

Cassandra

when i checked manage private keys i saw my user have permissions but i am still getting this error? – Tse

I don't see "Manage Private Keys" anywhere in MMC when right-clicking the certificate. – Parisparish

had that problem during a product roll-out with a new certificate. Really helped me out of s***. thx buddy! – Hydrography

@Parisparish Be sure to run MMC as an administrator. Try right clicking on a key in the personal store and see if the option shows up there. Also make sure you're using a .pfx certificate, not a .cer one. – Shiver

Answer 2

Seems like your certificate was created for signatures and not key exchange, what I suppose to be normal for SSL certificates.

If you look at the makecert documentation, you can see that the -sky switch lets you specify whether the certificate should be used for signatures or key exchange. You can try to create a self-signed certificate with type exchange and test whether the exception still occurs. Don't forget to put the self-signed certificate into the machine's trusted root certification authority folder in order to avoid exceptions that the certificate is not valid.

Italia

Used makecert,created a cert with the exchange param and imported. Updated the web.config to point to the new cert and getting the same error. Anything else I can try? – Epiphysis

Answer 3

Ensure also that the account name or group that needs to access the certificate ALSO has access to the folder hierarchy that the certificate resides in. If your certificate is hiding in, for example, 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys', and the account that needs to access it is 'NETWORK SERVICE', then 'NETWORK SERVICE' needs access to that full path. Just assigning rights to the file is not enough.

Camass

Answer 4

Same problem here. To fix the problem I added the following line to the <system.web> node of the web.config.

<httpRuntime targetFramework="4.7.2"/>

Knockwurst

Answer 5

I had this issue today and it was on a server cloned from another server. I had to uninstall the certs, reinstall the certs, and grant access to the certs (same manner as described in accepted answer).

Weyermann

Answer 6

I had the same issue and it's fixed by updating the IIS Application Pool to use the 'LocalSystem' Identity instead of the 'NETWORKSERVICE' Identity.

Mallis