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"

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?)

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)

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.

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.

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

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 *.

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 :-)

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.

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. .

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.

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

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

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

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

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.

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

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ó.

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

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

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.

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.

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).

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.