HttpWebRequest results in "The request was aborted: Could not create SSL/TLS secure channel"

Question

We've introduced a few .NET pages into a Classic ASP application. When a user hits one of the .NET pages we use an HttpWebRequest to get session variable values from the ASP side by sending the request to a Class ASP page with the name of the session variable we want. This approach works, except in the following situation.

On our production servers our IT folks have disabled the weak cipher algorithms with some registry hacking. We want to force 128 over 128 (or so I'm told by people who know more about security than I do). However, this causes our session-sharing request to abort with the following error.

The request was aborted: Could not create SSL/TLS secure channel

We turned on trace logging as described in this article. The relevant lines appear to be these.

System.Net Information: 0 : [3892] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 1b6acdd0:171a28, targetName = secure.xxx.com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [3892] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=AlgorithmMismatch).
System.Net.Sockets Verbose: 0 : [3892] Socket#18136189::Dispose()
System.Net Error: 0 : [3892] Exception in the HttpWebRequest#51004322:: - The request was aborted: Could not create SSL/TLS secure channel.
System.Net Error: 0 : [3892] Exception in the HttpWebRequest#51004322::GetResponse - The request was aborted: Could not create SSL/TLS secure channel.

The only nugget I can get from this information is that the problem is an AlgorithmMismatch, but I'm not sure what to do with that.

One thing I've read about, but we have not tried, is adding the following code before we make the request. Does it seem like there's any chance such a simple change could address this AlgorithmMismatch?

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3

Answer 1

We finally figured it out. In addition to disabling weak ciphers the IT guys tweaked a few other settings. They had set the Enabled (DWORD) value to 0 for HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client. That meant that the machine couldn't generate SSL requests. Changing Enabled from 0 to 1 for that key allowed everything to work.