C# HttpWebRequest SEC_I_RENEGOTIATE Intermittent Errors
Asked Answered
A

3

24

I'm working on login / logout functionality using SSL POST calls in a C# (.Net framework 3.5) application. Getting the response from the server via HttpWebRequest::BeginGetResponse() works 80% of the time, but the other 20% it is intermittently throwing:

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

I enabled SSL tracing using the suggested article from another question. That produced two distinct patterns in the request traces.

It seems that during execution, the error:

System.Net Error: 0 : [3680] Decrypt returned SEC_I_RENEGOTIATE.

is being received, causing re-init of the security context. When this happens, and it is successful, here is the output (noted that I omitted the actual address):

System.Net Error: 0 : [3680] Decrypt returned SEC_I_RENEGOTIATE.
System.Net Information: 0 : [3680] InitializeSecurityContext(credential =   System.Net.SafeFreeCredential_SECURITY, context = 4bec0d0:4c0a8a8, targetName = [omitted].com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [3680] InitializeSecurityContext(In-Buffer length=0, Out-Buffer length=78, returned code=ContinueNeeded).
System.Net Information: 0 : [7148] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4bec0d0:4c0a8a8, targetName = [omitted].com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [7148] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=ContinueNeeded).
System.Net Information: 0 : [7148] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4bec0d0:4c0a8a8, targetName = [omitted].com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [7148] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=ContinueNeeded).
System.Net Information: 0 : [7148] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4bec0d0:4c0a8a8, targetName = [omitted].com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [7148] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=1259, returned code=ContinueNeeded).
System.Net Information: 0 : [7148] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4bec0d0:4c0a8a8, targetName = [omitted].com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [7148] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=ContinueNeeded).
System.Net Information: 0 : [7148] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4bec0d0:4c0a8a8, targetName = [omitted].com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [7148] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=OK).
System.Net Information: 0 : [7148] Remote certificate: [Version]
  V1

When it fails:

System.Net Error: 0 : [3680] Decrypt returned SEC_I_RENEGOTIATE.
System.Net Information: 0 : [3680] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4bec0d0:4c0ab50, targetName = [omitted].com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [3680] InitializeSecurityContext(In-Buffer length=0, Out-Buffer length=78, returned code=ContinueNeeded).
System.Net Error: 0 : [3680] Exception in the HttpWebRequest#20730349:: - The request was aborted: Could not create SSL/TLS secure channel.
System.Net Verbose: 0 : [3680] HttpWebRequest#20730349::EndGetResponse()
System.Net Error: 0 : [3680] Exception in the HttpWebRequest#20730349::EndGetResponse - The request was aborted: Could not create SSL/TLS secure channel.

I can of course catch this exception, but what is the proper handling?

Is there a way for my application to prevent (or properly handle) these errors? When it happens it seems to error constantly for a time, but then start to work again after some undetermined number of requests.

Thanks!

Alumnus answered 3/6, 2011 at 21:12 Comment(9)
What kind of a server is this that you are accessing? Looks like .NEt tried once to renegotiate, but the server did not accept the handshake.Blanchard
An Apache web server. I don't have access to it directly. Here is the header: { Content-Length: 225 Content-Type: text/html Date: Fri, 03 Jun 2011 20:05:26 GMT Server: Apache X-Powered-By: PHP/5.2.8-pl2-gentoo }.Alumnus
I'm experiencing exactly the same problem. I also notice that keep-alive is not working in HTTPS, although the HttpWebRequest is configured with keep-alive and that it works perfectly in http. I've tested both ServicePointManager.SecurityProtocol SSL3 and TLS.Retractor
I have added a large bounty to get a different answer. Expect100Continue = true does not work for me and I really need this problem solved, it is the biggest problem our web app has. I get the exact same Decrypt returned SEC_I_RENEGOTIATE error, and the symptoms are the same as above "seems to error constantly for a time, but then start to work again". This is on a IIS 7.5 64 bit web server with a few hundred users a day and the error happens 1 - 3 times a day.Gentlewoman
I have tried to solve it like this - but without success: request.KeepAlive = false; request.ProtocolVersion = HttpVersion.Version10; ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; I have also tried Expect100Continue = false. It is very hard to test because it only happens after a few hours.Gentlewoman
Do you access for the Apache Log? Also, is the Apache clustered/load balanced or is it a single server? Same question for the .NET client, whether you are accessing this Apache server from one server or from a clustered clientsAppurtenant
And update: While I tried a few of the suggestions here, nothing helped. The errors eventually stopped occurring on my machine. I can only guess that something changed on the back-end. To momo: The setup is a single client, but I am not sure if the Apache server was load-balanced.Alumnus
The other server is on .NET. I did notice that their ssl cert has a not very well known root CA called "GTE CyberTrust Global Root"Gentlewoman
Same issue here. Have you ever fixed it?Traction
A
9

(For the original answer, see below.)

What this error usually means is that your client and server are not set to use the same type of encryption. Often, the simplest method of fixing this is explicitly setting the version to use in the client.

If you are using .NET 4.5 or newer, here are the options to try, in order from most secure to least secure:

  • ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
  • ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11;
  • ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;

If you are using .NET 4.0 or older, you can only use the last line above, as those versions do not support TLSv1.1 and TLSv1.2. It is highly recommended that you upgrade to .NET 4.5 to take advantage of TLSv1.2 support.

In addition to setting the SecurityProtocol property, you may also have to set: ServicePointManager.Expect100Continue = true;

If none of these settings helps, it likely means that your server only supports SSLv3 (or, even worse, SSLv2). If that is the case, upgrade your server! SSLv3 is broken and should no longer be used.


SSLv3 is NO LONGER considered secure. DO NOT use these settings! While this was the correct answer in 2011, it remains here only for historical reasons.

You need to add the following lines of code before your request:

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

From what I have seen, older versions (.NET 2 and/or Windows xp/2003 and older) used these as the default options but newer versions (.NET 3 and/or Windows Vista/2008 and newer) do not.

Albigenses answered 5/7, 2011 at 15:14 Comment(13)
This answer would work by turning off the stronger TLSv1 protocol.Telemann
@Moshe : this doesn't change anything in my case.Retractor
@MDE ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;Thursby
@Telemann - unfortunately, some web services I have worked with appear not to support TLSv1.Albigenses
I've tried Expect100 = true and Expect100 = false. The error still occurs both ways. Here is a related question that I asked before I knew it was a SEC_I_RENEGOTIATE error, it may provide more light on the subject: #6994141Gentlewoman
I've tried Expect100Continue = true, and SecurityProtocol = SecurityProtocolType.Ssl3. I still have the problem.Retractor
In my application both of those options were set by default. It had no impact.Alumnus
@MDE + Stryck Yes I still have the problem too. Have tried increasing the connectionManagement maxconnection setting in web.config to 24, but that did not help. I also tried a using() block around the code that reads the response stream, but that didnt help either. The problem occurs 2 or 3 times a day, always at the busiest times - I think it is a problem running out of a resource/connection, but dont know what the app is running out of.Gentlewoman
Still have this problem. Removed my initial upvote - this solution does not work at all.Gentlewoman
I would say that the first thing to do would be to check the certificates.. see https://mcmap.net/q/64521/-could-not-create-ssl-tls-secure-channel-could-the-problem-be-a-proxy-serverFouquiertinville
@Fouquiertinville That's almost definitely not the problem, considering that it does work 80% of the time from the same server.Albigenses
WCF Service had worked fine on Dev and Test servers, QC failed to resolve with "Could not create SSL/TLS secure channel." Added the above two lines to the beginning of my client, voila! Thanks!Bipinnate
This didn't work for me since the API I was using didn't support SSLv3. I was able to use this which did work: ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;Alkalimeter
B
4

This is not an explanation, nor a true solution: it's simply the most pragmatic way of dealing with this issue that we've found in our case (doing a WCF SOAP request over HTTPS using a client SSL cert with an Apache & Java based server).

Catch SecurityNegotiationException and retry on-the-spot (i.e. rather than reprocessing the message, if using msmq), and suppress reporting the exception in this case. Just inc a performance counter or something simple like that so you can track whether the problem gets any worse.

At the end of the day, this is just one of those innate network-related problems that your code needs to deal with.

Booze answered 14/2, 2012 at 20:41 Comment(1)
I have a similar intermittent problem and used an approach like you suggest.. the problem is that errors tend to raise and, in the end, it fails on every call it tries.. so this is good and desirable with self-solving troubles (those which users don't need to worry about) but finding the root of the problem is still the way to go :)Erotogenic
S
2

I thought I'd share my experience as I've been reading most of the stackoverflow questions on this lately:

Another approach to this which I've seen work is to consider HTTP Keep-Alive. With latest versions of .Net it uses HTTP 1.1 as default which means Keep-Alive is set to true and Expect100 on as well.

From my experience this creates stickiness on resources downstream and isn't reliable behind a load balancer.

Two choices

1) Recover and try again which seems slightly smelly. However as Khanfx mentions, network problems can happen ergo: fallacies of networks. TOPAZ is one way of solving this problem: https://msdn.microsoft.com/en-us/library/hh680901%28v=pandp.50%29.aspx?f=255&MSPPError=-2147217396

2) Turn off Keep-Alive either via HttpwebRequest or emitting a connection close header if using HttpClient.

HTH.

Staples answered 28/1, 2017 at 14:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.