Failure on HttpWebrequest with inner exception Authentication failed because the remote party has closed the transport stream

Question

Using C#, .Net 4.5, I'm trying to send out a web request through HttpWebRequest on a remote server. Please see the code below. I tried most of the solutions suggested by some forums but I always end up with the same error. Please see the stack trace below. The error is thrown when calling the request.GetReponse() method.

Additional info, basically, I'm trying to call the reloadSslCertificate function of vmware's vCenter component installed on a remote server. Currently, the error only happens on vCenter 5.5. It works fine in versions 5.1 and below.

        var uri = String.Format("https://{0}/some_url", serverName);         var request = (HttpWebRequest)WebRequest.Create(uri);         request.KeepAlive = true;         request.Accept = "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8";         request.Headers.Set(HttpRequestHeader.AcceptLanguage, "en-US,en;q=0.8");         request.Credentials = credential;         request.CookieContainer = cookieContainer;           var response = request.GetResponse(); 

Exception : System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream. at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.TlsStream.CallProcessAuthentication(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetResponse()

Thanks in advance.

Answer 1

I just want to share that this issue has already been resolved.

I just modified the part of the code where I set the security protocol before issuing the web request.

From:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; 

To:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls; 

As it turned out, vCenter 5.5 uses TLS as its SSL protocol in its configuration. I hope people may find this helpful when they encounter this same issue.

Answer 2

We ran into the same exception. In our case, the answer was incredibly similar to @Dennis Laping's answer. Another team had setup the service we were trying to hit within a Rancher load balancer, which by default did not allow TLS 1.0 or SSL3. It just so happens the current default for SecurityProtocol (without setting it) in .NET only allows TLS 1.0 or SSL3.

As soon as we set the SecurityProtocol as follows, everything worked fine:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; 

All that being said, the documentation for SecurityProtocol states that:

Your code should never implicitly depend on using a particular protection level, or on the assumption that a given security level is used by default. If your app depends on the use of a particular security level, you must explicitly specify that level and then check to be sure that it is actually in use on the established connection. Further, your code should be designed to be robust in the face of changes to which protocols are supported, as such changes are often made with little advance notice in order to mitigate emerging threats.

We'll be reevaluating what the best solution is to our protocol situation, but for now I hope this helps someone else.