Error de WCF "Esto podría deberse al hecho de que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS"

Question 1

Tengo un problema al usar una llamada WCF desde un servicio de Windows a mi servicio WCF que se ejecuta en mi servidor web. Esta llamada ha estado funcionando durante varias semanas, pero luego dejó de funcionar de repente y no ha funcionado desde entonces.

La excepción que obtengo es:

Ocurrió un error general System.ServiceModel.CommunicationException: Ocurrió un error al realizar la solicitud HTTP

y luego dice

Esto podría deberse a que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS. Esto también podría deberse a una falta de coincidencia del enlace de seguridad entre el cliente y el servidor.

La seguridad que estoy usando en ambos extremos es wsHttpBinding, sin ningún tipo de cifrado. También está usando HTTP, no HTTPS, así que no estoy seguro de por qué se queja de HTTPS.

El resto de la pila de excepciones interna es:

SystemNet.WebException: la conexión subyacente se cerró: se produjo un error inesperado en un envío. ---> System.IO.IOException: No se pueden escribir datos en la conexión de transporte: se proporcionó un argumento no válido. ---> System.Net.Sockets.SocketException: se proporcionó un argumento no válido en System.Net.Sockets.Socket.MultipleSend (BufferOffsetSize [] buffers, SocketFlags socketFlags) en System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetSize [] tampones)

También debo tener en cuenta que el punto en mi programa donde ocurre esto es en la línea "Ejecutar" de la llamada al servicio web, es decir, tan pronto como llamo al servicio web y le paso el objeto DataContract envuelto, explota.

Todo lo que hace este servicio es pasar una gran cantidad de XML (que se pasa como un objeto .NET a la llamada en el lado del cliente), con el que luego trabaja. Probablemente se estén transmitiendo entre 100 y 200 k de XML. Elevé los límites para los tamaños de datos en ambos extremos a más de 6 megas, pero eso no pareció ayudar.

¿Algunas ideas?

Más información sobre este tema:

Cuando duplicamos el entorno del cliente localmente, nos encontramos con que no podemos cargar grandes cantidades de XML a menos que hagamos los siguientes cambios: 1. En el servidor, establezca "maxRequestLength" en 100 MB (mucho más alto de lo que estamos enviando) 2. On el cliente, establecemos el valor de maxItemsInObjectGraph bajo la etiqueta dataContractSerializer en "2147483646".

Con estos cambios, nuestra instalación local se carga correctamente. Sin embargo, la instalación del cliente en su servidor aún falla. Lo interesante de notar es que una vez que hicimos el cambio de valor maxRequestLength en el servidor, nuestra instalación de prueba comenzó a arrojar un error relacionado específicamente con la configuración maxItemsInObjectGraph. Mientras que en el servidor de nuestro cliente, sigue ocurriendo el error "HTTP.sys" original.

Como señalé antes, no estamos usando SSL en absoluto, y hay otras 2 llamadas a servicios web que ejecutan y cargan XML de la misma manera. Sin embargo, dado que la llamada de servicio que no funciona transmite más datos, esto parece ser un problema de tamaño.

Sin embargo, si el problema que tiene el cliente es el mismo que tuvo nuestra instalación de prueba, no entiendo por qué el mensaje de error del cliente no estaría relacionado con el error ObjectGraph.

¿Es posible que solo obtengamos el error genérico de "parámetro no válido" "HTTP.sys" por cada posible error en el cliente (es decir, también está obteniendo el error objectGraph, pero simplemente no lo muestra?)

Question 2

Tuvimos este problema porque el servidor host se había actualizado para usar TLS V1.2 y nos estábamos conectando usando SSL estándar. Esta fue una actualización realizada como parte de las pruebas de penetración de los sitios. Vimos el problema en la conexión del código, pero no en los navegadores que van al wsdl. A continuación el código resuelto:

if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Tomado de aquí: ¿Cómo desactivo el respaldo SSL y uso solo TLS para conexiones salientes en .NET? (Mitigación de caniche)

Question 3

Tuve el mismo problema en un servicio que se ejecuta en IIS 7, el servicio se conecta a múltiples servidores de proveedores (algunos SSL, otros no) al agregar uno nuevo de estos (este nuevo proveedor era TLS 1.2) Obtendría el error después de algunas solicitudes. hecho a los servidores originales (SSL).

Para confirmar esto, simplemente registré el System.Net.ServicePointManager.SecurityProtocolantes de cada solicitud a cada proveedor.

Bajo y he aquí, después de reiniciar el servicio (o reiniciar el grupo de aplicaciones) obtendría el resultado, Ssl3, Tlspero después de algunas solicitudes a los servidores del proveedor original, esto cambió Ssl3y las solicitudes al servicio TLS dieron el error.

Para solucionarlo, simplemente hice lo que sugirió user369142. Antes de cada solicitud al nuevo servidor:

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

y no más errores.

Question 4

Tuve este problema con un enlace HTTPS verdadero y la misma excepción con "Esto podría deberse al hecho de que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso HTTPS ...". Después de verificar todo en el código y la configuración, parece que el mensaje de error no es tan engañoso como las excepciones internas, por lo que después de una verificación rápida, descubrimos que el puerto 443 fue enganchado por Skype (en el servidor de desarrollo). Te recomiendo que eches un vistazo a lo que detiene la solicitud (Fiddler podría ayudar aquí) y te asegures de que puedes acceder al frente del servicio (ver el .svc en tu navegador) y sus metadatos.

Buena suerte.

Question 5

En mi caso, tuve que habilitar SchUseStrongCrypto.Net. Esto obliga al servidor a realizar la conexión mediante TLS 1.0, 1.1 o 1.2. Sin SchUseStrongCryptohabilitado, la conexión intentaba usar SSL 3.0, que estaba deshabilitado en mi punto final remoto.

Claves de registro para permitir el uso de criptografía fuerte:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Question 6

Para nosotros, este error se debió a que la computadora del desarrollador que ejecuta el servicio tenía IIS configurado para enlazar el puerto 443 solo en 127.0.0.1.

En el Administrador de IIS, haga clic con el botón derecho en el sitio web y seleccione Editar enlaces. Si la entrada de Puerto 443tiene una dirección IP 127.0.0.1, cámbiela a *.

Question 7

Después de mucho buscar y tomar el nombre del señor en vano, finalmente lo obtuve.He instalado TLS 1.2 en el servidor donde se está ejecutando mi servicio wcf.Mi cliente se configuró correctamente pero se construyó en .NET 4.5.1 mientras que el wcf estaba en .NET 4.6.1. Tanto el cliente como el servidor deben tener la misma versión .NET si está utilizando TLS 1.2. Espero que algún día ayude a alguien :-)

Question 8

Cambie su aplicación cliente a 4.5 y superior. SI tiene 4.5, use: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 según sea necesario o puede actualizar su aplicación a más de 4.6.1.

Question 9

Recientemente, ocurrió exactamente este mismo problema y resultó ser causado por la actualización de Microsoft KB980436 ( http://support.microsoft.com/KB/980436 ) que se instaló en la computadora que llama. La solución para nosotros, además de desinstalarla por completo, fue seguir las instrucciones en el sitio de KB para configurar UseScsvForTls DWORD en el registro en 1. Si ve que esta actualización está instalada en su sistema de llamadas, es posible que desee intentarlo. .

Question 10

Tuve este problema al ejecutar cajas XP SP3 más antiguas contra IIS y glassfish en Amazon AWS. Amazon cambió la configuración predeterminada del equilibrador de carga para NO habilitar el cifrado DES-CBC3-SHA. Debe habilitar eso en amazon ELB si desea permitir que XP TLS 1.0 anterior funcione contra ELB para HTTPS; de lo contrario, obtendrá este error. Los cifrados se pueden cambiar en ELB yendo a la pestaña del oyente en la consola y haciendo clic en el cifrado junto al oyente en particular que está tratando de hacer funcionar.

Question 11

Si su servicio WCF usa .net framework 4.0 y alguien ha deshabilitado TLS 1.0 en el servidor, verá esta excepción. Debido a que .net 4.0 no es compatible con las versiones superiores de TLS.

Protocolos compatibles: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx

Question 12

He visto estas excepciones particulares relacionadas con problemas de tipos de datos complejos, consulte la siguiente publicación si está pasando colecciones o enumeraciones:

Tipos de datos complejos

Question 13

Si está utilizando transfer mode = streamed, intente cambiarlo a buffer.

Si este no es el problema, podría publicar su configuración.

Question 14

Como todo funcionó bien durante semanas y luego se detuvo, dudo que esto tenga algo que ver con su código. Quizás el error se produce cuando el servicio se activa dentro de IIS / ASP.NET, no cuando se llama a su código. El tiempo de ejecución podría simplemente verificar la configuración del sitio web y arrojar un mensaje de error genérico que no tiene nada que ver con el servicio.

Mi sospecha es que un certificado ha caducado o que los enlaces están configurados incorrectamente. Si el sitio web está mal configurado para HTTPS, ya sea que su código los use o no, es posible que reciba este error.

Question 15

Intente navegar por el servicio en el navegador y en el modo Https, si no es navegable, demuestra la razón de este error. Ahora, para resolver este error, debe verificar:

Puerto https, compruebe si otros recursos no lo están utilizando (sitio web)
Verifique si el certificado para https está configurado correctamente o no (verifique la autoridad de firma, certificado autofirmado, usando certificado múltiple)
comprobar el enlace y la configuración del servicio WCF para el modo Https

Question 16

Nuestro problema era simplemente que el número de puerto en el punto final estaba configurado incorrectamente en 8080. Lo cambiamos a 8443 y funcionó.

Question 17

En lugar de configurar explícitamente el protocolo de seguridad, una mejor manera es configurar web.config <compilation targetFramework = "4.5"> o superior.

Question 18

Resolví mi problema actualizando mi versión .NetFramework de 4.5.2 a 4.7.2.

Question 19

Recientemente experimenté esto:

System.ServiceModel.CommunicationException:

Se produjo un error al realizar la solicitud HTTP a http://example.com/WebServices/SomeService.svc . Esto podría deberse a que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS. Esto también podría deberse a una falta de coincidencia del enlace de seguridad entre el cliente y el servidor.

---> System.Net.WebException: la conexión subyacente se cerró: se produjo un error inesperado en un envío.

---> System.IO.IOException: No se pueden escribir datos en la conexión de transporte: el host remoto cerró a la fuerza una conexión existente.

Un administrador me informó que el grupo de aplicaciones de IIS que alojaba el servicio web se reciclaba automáticamente después de quedarse sin memoria. El error en el cliente ocurrió cuando se recicló el grupo de aplicaciones.

El aumento de la memoria disponible para el grupo de aplicaciones resolvió el problema inmediato.

Question 20

Nuestras aplicaciones se vieron obligadas recientemente a pasar de SSL a TLS a través de una actualización del sistema operativo del dispositivo de red (F5). Solucionamos este error volviendo a generar los certificados autofirmados. Espero que esto ayude a alguien en el futuro a resolver el problema, ya que pasamos varias ventanas de mantenimiento solucionando problemas antes de llegar a la solución.

Question 21

Recientemente experimenté esto:

System.ServiceModel.CommunicationException:

Se produjo un error al realizar la solicitud HTTP a http://example.com/WebServices/SomeService.svc . Esto podría deberse a que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS. Esto también podría deberse a una falta de coincidencia del enlace de seguridad entre el cliente y el servidor.

---> System.Net.WebException: la conexión subyacente se cerró: se produjo un error inesperado en un envío.

---> System.IO.IOException: No se pueden escribir datos en la conexión de transporte: el host remoto cerró a la fuerza una conexión existente.

¡Nuestra licencia del proxy bluecoat venció! por lo que no fue posible comunicarse con la parte externa (Internet).

Question 22

Tuvimos el mismo problema y, en nuestro caso, se resolvió reinstalando el certificado y creando el enlace nuevamente. Lo que nos llevó allí fue el hecho de que incluso obtener un simple archivo de imagen png en el sitio da el mismo error.

Answer 1

Tengo un problema al usar una llamada WCF desde un servicio de Windows a mi servicio WCF que se ejecuta en mi servidor web. Esta llamada ha estado funcionando durante varias semanas, pero luego dejó de funcionar de repente y no ha funcionado desde entonces.

La excepción que obtengo es:

Ocurrió un error general System.ServiceModel.CommunicationException: Ocurrió un error al realizar la solicitud HTTP

y luego dice

Esto podría deberse a que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS. Esto también podría deberse a una falta de coincidencia del enlace de seguridad entre el cliente y el servidor.

La seguridad que estoy usando en ambos extremos es wsHttpBinding, sin ningún tipo de cifrado. También está usando HTTP, no HTTPS, así que no estoy seguro de por qué se queja de HTTPS.

El resto de la pila de excepciones interna es:

SystemNet.WebException: la conexión subyacente se cerró: se produjo un error inesperado en un envío. ---> System.IO.IOException: No se pueden escribir datos en la conexión de transporte: se proporcionó un argumento no válido. ---> System.Net.Sockets.SocketException: se proporcionó un argumento no válido en System.Net.Sockets.Socket.MultipleSend (BufferOffsetSize [] buffers, SocketFlags socketFlags) en System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetSize [] tampones)

También debo tener en cuenta que el punto en mi programa donde ocurre esto es en la línea "Ejecutar" de la llamada al servicio web, es decir, tan pronto como llamo al servicio web y le paso el objeto DataContract envuelto, explota.

Todo lo que hace este servicio es pasar una gran cantidad de XML (que se pasa como un objeto .NET a la llamada en el lado del cliente), con el que luego trabaja. Probablemente se estén transmitiendo entre 100 y 200 k de XML. Elevé los límites para los tamaños de datos en ambos extremos a más de 6 megas, pero eso no pareció ayudar.

¿Algunas ideas?

Más información sobre este tema:

Cuando duplicamos el entorno del cliente localmente, nos encontramos con que no podemos cargar grandes cantidades de XML a menos que hagamos los siguientes cambios: 1. En el servidor, establezca "maxRequestLength" en 100 MB (mucho más alto de lo que estamos enviando) 2. On el cliente, establecemos el valor de maxItemsInObjectGraph bajo la etiqueta dataContractSerializer en "2147483646".

Con estos cambios, nuestra instalación local se carga correctamente. Sin embargo, la instalación del cliente en su servidor aún falla. Lo interesante de notar es que una vez que hicimos el cambio de valor maxRequestLength en el servidor, nuestra instalación de prueba comenzó a arrojar un error relacionado específicamente con la configuración maxItemsInObjectGraph. Mientras que en el servidor de nuestro cliente, sigue ocurriendo el error "HTTP.sys" original.

Como señalé antes, no estamos usando SSL en absoluto, y hay otras 2 llamadas a servicios web que ejecutan y cargan XML de la misma manera. Sin embargo, dado que la llamada de servicio que no funciona transmite más datos, esto parece ser un problema de tamaño.

Sin embargo, si el problema que tiene el cliente es el mismo que tuvo nuestra instalación de prueba, no entiendo por qué el mensaje de error del cliente no estaría relacionado con el error ObjectGraph.

¿Es posible que solo obtengamos el error genérico de "parámetro no válido" "HTTP.sys" por cada posible error en el cliente (es decir, también está obteniendo el error objectGraph, pero simplemente no lo muestra?)

Answer 2

Dice que dejó de funcionar, ¿ha cambiado algún código o configuración que pueda haber sido responsable de esto? ¿Puede publicar algún código para el método al que está llamando con tipos de datos que se están pasando?

Tanner

Answer 3

Lo desenterraré y lo publicaré. Creo que básicamente estoy pasando una matriz de objetos "AppointmentData", que están definidos en el material DataContract. Sin embargo, ciertamente son objetos complejos, así que revisaré tu publicación. ¡Gracias!

Sam Schutte

Answer 4

Ah, y no se ha modificado ningún código o configuración; funcionó bien durante semanas y luego simplemente se detuvo. Es posible que la configuración del firewall del cliente también se haya cambiado, pero lo extraño es que el servicio que está haciendo la llamada WCF puede llamar a otros 2 métodos de servicio WCF, y también tiene la capacidad de enviarme un correo electrónico con el contenido de la excepción ... en 2 de las 3 llamadas WCF, pero no en la última.

Sam Schutte

Answer 5

2

Siempre desconfío de los "errores generales" que luego sugieren una posibilidad porque realmente no sabes si la sugerencia es una pista falsa o no. ¿Puede probar configurando security = none? Si la llamada de servicio funciona, nos dice que el certificado (o al menos la seguridad) es un problema. También me gustaría ver la configuración en ambos lados.

Mike L

Answer 6

Tendré que comprobarlo, pero estoy bastante seguro de que la seguridad ya no está configurada ...

Sam Schutte

Answer 7

73

Tuvimos este problema porque el servidor host se había actualizado para usar TLS V1.2 y nos estábamos conectando usando SSL estándar. Esta fue una actualización realizada como parte de las pruebas de penetración de los sitios. Vimos el problema en la conexión del código, pero no en los navegadores que van al wsdl. A continuación el código resuelto:

if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Tomado de aquí: ¿Cómo desactivo el respaldo SSL y uso solo TLS para conexiones salientes en .NET? (Mitigación de caniche)

user369142
fuente

¡Gracias! Eso me ayudó. Tuve que configurar esto si llamaba a una DLL de C # haciendo una llamada SOAP desde una aplicación de C ++. Si se llamó a la misma DLL de C # desde la aplicación C #, esto no era necesario.

píxel

en mi caso: a) necesitaba agregar using System.Neta mi archivo. b) el valor de SecurityProtocol era "Default". Decidí eliminar el "if" y asignar SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 sin preguntar primero. HTH, Marcelo

Marcelo Finki

1

2020. Misma solución.

Anton Krouglov

Answer 8

¡Gracias! Eso me ayudó. Tuve que configurar esto si llamaba a una DLL de C # haciendo una llamada SOAP desde una aplicación de C ++. Si se llamó a la misma DLL de C # desde la aplicación C #, esto no era necesario.

píxel

Answer 9

en mi caso: a) necesitaba agregar using System.Neta mi archivo. b) el valor de SecurityProtocol era "Default". Decidí eliminar el "if" y asignar SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 sin preguntar primero. HTH, Marcelo

Marcelo Finki

Answer 10

1

2020. Misma solución.

Anton Krouglov

Answer 11

Tuve el mismo problema en un servicio que se ejecuta en IIS 7, el servicio se conecta a múltiples servidores de proveedores (algunos SSL, otros no) al agregar uno nuevo de estos (este nuevo proveedor era TLS 1.2) Obtendría el error después de algunas solicitudes. hecho a los servidores originales (SSL).

Para confirmar esto, simplemente registré el System.Net.ServicePointManager.SecurityProtocolantes de cada solicitud a cada proveedor.

Bajo y he aquí, después de reiniciar el servicio (o reiniciar el grupo de aplicaciones) obtendría el resultado, Ssl3, Tlspero después de algunas solicitudes a los servidores del proveedor original, esto cambió Ssl3y las solicitudes al servicio TLS dieron el error.

Para solucionarlo, simplemente hice lo que sugirió user369142. Antes de cada solicitud al nuevo servidor:

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

y no más errores.

Answer 12

Necesitará un mínimo de .NET 4.5+ para usar TLS 1.2+. Fuente: blogs.perfficient.com/microsoft/2016/04/tsl-1-2-and-net-support

xx1xx

Answer 13

Muchas gracias, ¿podría usarse con enteros para la enumeración en su lugar: System.Net.ServicePointManager.SecurityProtocol = 123 => enum1 | enum2, etc. Para otros marcos?

MirlvsMaximvs

Answer 14

No es necesario configurar esto antes de cada solicitud, solo configúrelo una vez en el evento de inicio de la aplicación, es una propiedad estática que está configurando.

user369142

Answer 15

Tuve este problema con un enlace HTTPS verdadero y la misma excepción con "Esto podría deberse al hecho de que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso HTTPS ...". Después de verificar todo en el código y la configuración, parece que el mensaje de error no es tan engañoso como las excepciones internas, por lo que después de una verificación rápida, descubrimos que el puerto 443 fue enganchado por Skype (en el servidor de desarrollo). Te recomiendo que eches un vistazo a lo que detiene la solicitud (Fiddler podría ayudar aquí) y te asegures de que puedes acceder al frente del servicio (ver el .svc en tu navegador) y sus metadatos.

Buena suerte.

Answer 16

En mi caso, tuve que habilitar SchUseStrongCrypto.Net. Esto obliga al servidor a realizar la conexión mediante TLS 1.0, 1.1 o 1.2. Sin SchUseStrongCryptohabilitado, la conexión intentaba usar SSL 3.0, que estaba deshabilitado en mi punto final remoto.

Claves de registro para permitir el uso de criptografía fuerte:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Answer 17

Para nosotros, este error se debió a que la computadora del desarrollador que ejecuta el servicio tenía IIS configurado para enlazar el puerto 443 solo en 127.0.0.1.

En el Administrador de IIS, haga clic con el botón derecho en el sitio web y seleccione Editar enlaces. Si la entrada de Puerto 443tiene una dirección IP 127.0.0.1, cámbiela a *.

Answer 18

5

Después de mucho buscar y tomar el nombre del señor en vano, finalmente lo obtuve.He instalado TLS 1.2 en el servidor donde se está ejecutando mi servicio wcf.Mi cliente se configuró correctamente pero se construyó en .NET 4.5.1 mientras que el wcf estaba en .NET 4.6.1. Tanto el cliente como el servidor deben tener la misma versión .NET si está utilizando TLS 1.2. Espero que algún día ayude a alguien :-)

Sotiris Zegiannis
fuente

2

Esto tendría que ser un error si ese fuera el caso, el protocolo no debería diferir según la versión .NET, y sin mencionar los servicios o clientes que ni siquiera usan .NET.

Joel McBeth

Esta pista resolvió mi problema. Tenía un proyecto WPF con una referencia a otro proyecto B. El proyecto B era 4.5.2 y el proyecto WPF era 4.6.1. Hacer ambos 4.5.2 resolvió el problema.

Ignacio Hagopian

Answer 19

2

Esto tendría que ser un error si ese fuera el caso, el protocolo no debería diferir según la versión .NET, y sin mencionar los servicios o clientes que ni siquiera usan .NET.

Joel McBeth

Answer 20

Esta pista resolvió mi problema. Tenía un proyecto WPF con una referencia a otro proyecto B. El proyecto B era 4.5.2 y el proyecto WPF era 4.6.1. Hacer ambos 4.5.2 resolvió el problema.

Ignacio Hagopian

Answer 21

Cambie su aplicación cliente a 4.5 y superior. SI tiene 4.5, use: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 según sea necesario o puede actualizar su aplicación a más de 4.6.1.

Answer 22

Recientemente, ocurrió exactamente este mismo problema y resultó ser causado por la actualización de Microsoft KB980436 ( http://support.microsoft.com/KB/980436 ) que se instaló en la computadora que llama. La solución para nosotros, además de desinstalarla por completo, fue seguir las instrucciones en el sitio de KB para configurar UseScsvForTls DWORD en el registro en 1. Si ve que esta actualización está instalada en su sistema de llamadas, es posible que desee intentarlo. .

Answer 23

¿Tus llamadas usaban HTTPS? ¿O estaban desencriptados como los OP?

Roufamatic

Answer 24

Tuve este problema al ejecutar cajas XP SP3 más antiguas contra IIS y glassfish en Amazon AWS. Amazon cambió la configuración predeterminada del equilibrador de carga para NO habilitar el cifrado DES-CBC3-SHA. Debe habilitar eso en amazon ELB si desea permitir que XP TLS 1.0 anterior funcione contra ELB para HTTPS; de lo contrario, obtendrá este error. Los cifrados se pueden cambiar en ELB yendo a la pestaña del oyente en la consola y haciendo clic en el cifrado junto al oyente en particular que está tratando de hacer funcionar.

Answer 25

2

Si su servicio WCF usa .net framework 4.0 y alguien ha deshabilitado TLS 1.0 en el servidor, verá esta excepción. Debido a que .net 4.0 no es compatible con las versiones superiores de TLS.

Protocolos compatibles: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx

usuario1069816
fuente

4

En realidad, existe una solución alternativa que aún puede utilizar: ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; //TLS 1.2y funcionará en NET 4.0.

F34R

@ F34R su comentario resolvió mi problema para una aplicación .NET 4.0 que intentaba hacer una solicitud SOAP a un punto final que se convirtió recientemente de http a https. Con el apoyo de blogs.perfficient.com/microsoft/2016/04/tsl-1-2-and-net-support

Wesley Musgrove

Answer 26

4

En realidad, existe una solución alternativa que aún puede utilizar: ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; //TLS 1.2y funcionará en NET 4.0.

F34R

Answer 27

@ F34R su comentario resolvió mi problema para una aplicación .NET 4.0 que intentaba hacer una solicitud SOAP a un punto final que se convirtió recientemente de http a https. Con el apoyo de blogs.perfficient.com/microsoft/2016/04/tsl-1-2-and-net-support

Wesley Musgrove

Answer 28

1

He visto estas excepciones particulares relacionadas con problemas de tipos de datos complejos, consulte la siguiente publicación si está pasando colecciones o enumeraciones:

Tipos de datos complejos

Curtidor
fuente

Analizamos el problema del tipo de datos: solo estamos enviando objetos .NET antiguos que están definidos en nuestro dataContract, sin enumerables ni cosas por el estilo. Sin embargo, instalamos algunas de las herramientas de rastreo de depuración mencionadas en este artículo y pudimos ver nuestras 2 llamadas de trabajo, pero no apareció nada en la 3ª llamada "no funcional". Esto me indica que ni siquiera está saliendo de la máquina cliente.

Sam Schutte

4

@SamSchutte: ¿se resolvió este error alguna vez? ¿Podría proporcionarnos cuál fue la solución?

VoodooChild

Answer 29

Analizamos el problema del tipo de datos: solo estamos enviando objetos .NET antiguos que están definidos en nuestro dataContract, sin enumerables ni cosas por el estilo. Sin embargo, instalamos algunas de las herramientas de rastreo de depuración mencionadas en este artículo y pudimos ver nuestras 2 llamadas de trabajo, pero no apareció nada en la 3ª llamada "no funcional". Esto me indica que ni siquiera está saliendo de la máquina cliente.

Sam Schutte

Answer 30

4

@SamSchutte: ¿se resolvió este error alguna vez? ¿Podría proporcionarnos cuál fue la solución?

VoodooChild

Answer 31

1

Si está utilizando transfer mode = streamed, intente cambiarlo a buffer.

Si este no es el problema, podría publicar su configuración.

Shiraz Bhaiji
fuente

Answer 32

Como todo funcionó bien durante semanas y luego se detuvo, dudo que esto tenga algo que ver con su código. Quizás el error se produce cuando el servicio se activa dentro de IIS / ASP.NET, no cuando se llama a su código. El tiempo de ejecución podría simplemente verificar la configuración del sitio web y arrojar un mensaje de error genérico que no tiene nada que ver con el servicio.

Mi sospecha es que un certificado ha caducado o que los enlaces están configurados incorrectamente. Si el sitio web está mal configurado para HTTPS, ya sea que su código los use o no, es posible que reciba este error.

Answer 33

Intente navegar por el servicio en el navegador y en el modo Https, si no es navegable, demuestra la razón de este error. Ahora, para resolver este error, debe verificar:

Puerto https, compruebe si otros recursos no lo están utilizando (sitio web)
Verifique si el certificado para https está configurado correctamente o no (verifique la autoridad de firma, certificado autofirmado, usando certificado múltiple)
comprobar el enlace y la configuración del servicio WCF para el modo Https

Answer 34

1

Nuestro problema era simplemente que el número de puerto en el punto final estaba configurado incorrectamente en 8080. Lo cambiamos a 8443 y funcionó.

tntice
fuente

Answer 35

1

En lugar de configurar explícitamente el protocolo de seguridad, una mejor manera es configurar web.config <compilation targetFramework = "4.5"> o superior.

Vijay Jagdale
fuente

Answer 36

1

Resolví mi problema actualizando mi versión .NetFramework de 4.5.2 a 4.7.2.

Mohammad
fuente

Answer 37

Recientemente experimenté esto:

System.ServiceModel.CommunicationException:

Se produjo un error al realizar la solicitud HTTP a http://example.com/WebServices/SomeService.svc . Esto podría deberse a que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS. Esto también podría deberse a una falta de coincidencia del enlace de seguridad entre el cliente y el servidor.

---> System.Net.WebException: la conexión subyacente se cerró: se produjo un error inesperado en un envío.

---> System.IO.IOException: No se pueden escribir datos en la conexión de transporte: el host remoto cerró a la fuerza una conexión existente.

Un administrador me informó que el grupo de aplicaciones de IIS que alojaba el servicio web se reciclaba automáticamente después de quedarse sin memoria. El error en el cliente ocurrió cuando se recicló el grupo de aplicaciones.

El aumento de la memoria disponible para el grupo de aplicaciones resolvió el problema inmediato.

Answer 38

Nuestras aplicaciones se vieron obligadas recientemente a pasar de SSL a TLS a través de una actualización del sistema operativo del dispositivo de red (F5). Solucionamos este error volviendo a generar los certificados autofirmados. Espero que esto ayude a alguien en el futuro a resolver el problema, ya que pasamos varias ventanas de mantenimiento solucionando problemas antes de llegar a la solución.

Answer 39

Recientemente experimenté esto:

System.ServiceModel.CommunicationException:

Se produjo un error al realizar la solicitud HTTP a http://example.com/WebServices/SomeService.svc . Esto podría deberse a que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS. Esto también podría deberse a una falta de coincidencia del enlace de seguridad entre el cliente y el servidor.

---> System.Net.WebException: la conexión subyacente se cerró: se produjo un error inesperado en un envío.

---> System.IO.IOException: No se pueden escribir datos en la conexión de transporte: el host remoto cerró a la fuerza una conexión existente.

¡Nuestra licencia del proxy bluecoat venció! por lo que no fue posible comunicarse con la parte externa (Internet).

Answer 40

Tuvimos el mismo problema y, en nuestro caso, se resolvió reinstalando el certificado y creando el enlace nuevamente. Lo que nos llevó allí fue el hecho de que incluso obtener un simple archivo de imagen png en el sitio da el mismo error.

Error de WCF "Esto podría deberse al hecho de que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso de HTTPS"

Respuestas: