c# - transporte - se ha terminado la conexión error inesperado de envío webclient

Fallo en HttpWebrequest con excepción interna La autenticación falló porque la parte remota ha cerrado el flujo de transporte

Question

Utilizando C #, .Net 4.5, estoy intentando enviar una solicitud web a través de HttpWebRequest en un servidor remoto. Por favor, consulte el código de abajo. Probé la mayoría de las soluciones sugeridas por algunos foros, pero siempre termino con el mismo error. Por favor, vea el seguimiento de la pila a continuación. El error se produce al llamar al método request.GetReponse ().

Información adicional, básicamente, estoy intentando llamar a la función reloadSslCertificate del componente vCware de vmware instalado en un servidor remoto. Actualmente, el error solo ocurre en vCenter 5.5. Funciona bien en las versiones 5.1 y siguientes.

 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();

Excepción: System.Net.WebException: la conexión subyacente se cerró: se produjo un error inesperado en un envío. ---> System.IO.IOException: la autenticación falló porque la parte remota ha cerrado el flujo de transporte. en System.Net.Security.SslState.StartReadFrame (Byte [] búfer, Int32 readBytes, AsyncProtocolRequest asyncRequest) en System.Net.Security.SslState.p.n.v.ns.StartReceiveBlob (Byte [] buffer). CheckCompletionBeforeNextReceive (Mensaje de ProtocolToken, AsyncProtocolRequestSyncRequest) en System.Net.Security.SslState.endartSendBlob (Bytes de los campos de los juegos), Recuento Int32, AsyncProtocolRequest) en System. asyncRequest) en System.Net.Security.SslState.ProcessAuthentication (LazyAsyncResult lazyResult) en System.Net.TlsStream. System.Threading.ExecutionContext.Run (Ejecución de ExecutionContextContext, Devolución de llamada ContextCallback, Estado del objeto, Boolean preserveSy ncCtx) en System.Threading.ExecutionContext.Run (Ejecución de ExecutionContextContext, devolución de llamada ContextCallback, estado del objeto) en System.Net.TlsStream.ProcessAuthentication (LazyAsyncResult resultado) en System.Net.TlsStream.Write (Byte [1]) tamaño) en System.Net.PooledStream.Write (Byte [] buffer, Int32 offset, Int32 tamaño) en System.Net.ConnectStream.WriteHeaders (Boolean async) --- Fin del rastreo de la pila de excepciones interna --- en System.Net .HttpWebRequest.GetResponse ()

Gracias por adelantado.

Answer 1

Nos topamos con la misma excepción. En nuestro caso, la respuesta fue increíblemente similar a la respuesta de @Dennis Laping. Otro equipo había configurado el servicio que intentábamos alcanzar dentro de un equilibrador de carga Rancher , que de forma predeterminada no permitía TLS 1.0 o SSL3. Sucede que el valor predeterminado actual para SecurityProtocol (sin configurarlo) en .NET solo permite TLS 1.0 o SSL3.

Tan pronto como configuramos el SecurityProtocol siguiente manera, todo funcionó bien:

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

Dicho todo esto, la documentación de SecurityProtocol establece que:

Su código nunca debe depender implícitamente del uso de un nivel de protección particular, o de la suposición de que un nivel de seguridad determinado se usa de forma predeterminada. Si su aplicación depende del uso de un nivel de seguridad particular, debe especificar ese nivel explícitamente y luego verificar que esté realmente en uso en la conexión establecida. Además, su código debe diseñarse para ser sólido frente a los cambios a los que se admiten los protocolos, ya que estos cambios a menudo se realizan con poca antelación para mitigar las amenazas emergentes.

Volveremos a evaluar cuál es la mejor solución para nuestra situación de protocolo, pero por ahora espero que esto ayude a alguien más.

Answer 2

Solo quiero compartir que este problema ya ha sido resuelto.

Acabo de modificar la parte del código donde configuro el protocolo de seguridad antes de emitir la solicitud web.

Desde:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

A:

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

Al final resultó que, vCenter 5.5 utiliza TLS como su protocolo SSL en su configuración. Espero que la gente pueda encontrar esto útil cuando se encuentren con el mismo problema.

Answer 3

Vea este enlace, funcionó para mí: ¿Cómo hacer HTTPS con TcpClient como lo hace HttpWebRequest?

Dim trust_all_certificates As New CertificateOverride
ServicePointManager.ServerCertificateValidationCallback = AddressOf trust_all_certificates.RemoteCertificateValidationCallback
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3
Public Class CertificateOverride
Public Function RemoteCertificateValidationCallback(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
''CertEXPIRED = 2148204801
''CertVALIDITYPERIODNESTING = 2148204802
''CertPATHLENCONST = 2148204804
''CertROLE = 2148204803
''CertCRITICAL = 2148204805
''CertPURPOSE = 2148204806
''CertISSUERCHAINING = 2148204807
''CertMALFORMED = 2148204808
''CertUNTRUSTEDROOT = 2148204809
''CertCHAINING = 2148204810
''CertREVOKED = 2148204812
''CertUNTRUSTEDTESTROOT = 2148204813
''CertREVOCATION_FAILURE = 2148204814
''CertCN_NO_MATCH = 2148204815
''CertWRONG_USAGE = 2148204816
''CertUNTRUSTEDCA = 2148204818
Return True
End Function
End Class

PD

Inserté esta línea de código antes solo para estar seguro de que se acepta el certificado del lado del servidor: ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3