Re: could not create ssl/tls secure channel web service
If one of your ASP.NET applications need to access to a certificate from the certificate store along with its private key, you'll probably run into trouble. The private key is saved in a special file with an unguessable name. It's not readable for everyone (for obvious reasons). The lack of file access is not very intuitive, as you can see the certificate in the Certificate MMC snap-in, and it will claim that "this certificate has a corresponding private key". You'll still have to give the application pool's user read access to the key.
There are some differences in how to do this for the 2008 R2 and the 2003 server, here's a short explanation and some useful resources for both versions.
Windows 2008 R2 server On the 2008 R2 server, the lack of read access to the private key will manifest itself as this exception:
Exception Details:System.Security.Cryptography.CryptographicException: Keyset does not exist
A notable new feature in the 2008 R2 server (with IIS 7.5) is that applications pools run under their own user. You need to figure out which identity the application pool is running as, e.g.: IIS AppPool\DefaultAppPool.
The security properties of the private key file can be set through the certificate MMC snap-in. (Start -> run -> "mmc" -> Add snap-in -> Certificates -> Local Machine/Personal cert store). You need to give the application pool user read access to the private key file.
Note: the 2008 server (not R2) uses the same user execution model as the 2003 server, keep reading if you have one of those.
Windows 2003 server On the 2003 server, the exception is even less informative than on the 2008 R2.
Exception Details: System.Security.Cryptography.CryptographicException: The handle is invalid.
The challenge is still the lack of read access to the private key. Here's an explanation on how to use the WSE tool to adjust the private key's security settings. You can also check out Microsoft's findprivatekey.exe tool.
You'll probably need to give the user NETWORKSERVICE read access to the private key file, unless you've changed the application pool user defaults.