visual studio net example crear xml wcf web-services wcf-security

xml - net - web service c# visual studio 2017



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

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

Tengo un problema al usar una llamada WCF de 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:

Se produjo un error general System.ServiceModel.CommunicationException: se produjo un error al realizar la solicitud HTTP

y luego dice

Esto podría deberse al hecho de que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso 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 encriptación. También solo usa HTTP, no HTTPS, por lo 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 puede 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 [] buffers)

También debo señalar que el punto en mi programa donde esto ocurre está en la línea "Ejecutar" de la llamada al servicio web, es decir, en cuanto llamo al servicio web y lo transfiero al objeto DataContract envuelto, explota.

Todo lo que este servicio está haciendo es pasar una gran cantidad de XML (pasado como un objeto .NET a la llamada en el lado del cliente), que luego hace un poco de trabajo. Probablemente se están transmitiendo aproximadamente 100-200k de XML. Aumenté 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?

Algo más de información sobre este tema:

Cuando duplicamos localmente el entorno del cliente, descubrimos 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 de lo que estamos enviando) 2. En el cliente, establecemos el valor de maxItemsInObjectGraph bajo la etiqueta dataContractSerializer en "2147483646".

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

Como noté 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 está teniendo el cliente es el mismo que tenía 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 error posible en el cliente (es decir, realmente está obteniendo el error objectGraph, pero simplemente no lo está mostrando?)

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

Mi sospecha es que un certificado ha expirado 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 esté recibiendo este error.

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 fue construido 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 de .NET si está utilizando TLS 1.2. Espero que ayude a alguien algún día :-)

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

Claves de registro para habilitar 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

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

Tipos de datos complejos

Hemos tenido casi este mismo problema exactamente recientemente y resultó ser causado por la actualización de Microsoft KB980436 ( http://support.microsoft.com/KB/980436 ) que se está instalando en la computadora que llama. La solución para nosotros, aparte de desinstalarla directamente, era seguir las instrucciones en el sitio de KB para establecer UseScsvForTls DWORD en el registro en 1. Si ve que esta actualización está instalada en su sistema de llamadas, es posible que desee darle una oportunidad .

Intente buscar el servicio en el navegador y en el modo Https, si no es visible, entonces prueba el motivo de este error. Ahora, para resolver este error, debe verificar:

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

Nuestras aplicaciones fueron forzadas recientemente a pasar de SSL a TLS a través de una actualización de sistema operativo de 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 por la solución de problemas de múltiples ventanas de mantenimiento antes de llegar a la solución.

Para nosotros, este error se debió a que la computadora del desarrollador que ejecutaba el servicio tenía IIS configurado para vincular el puerto 443 en 127.0.0.1 únicamente.

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

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 al hecho de que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso 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ó forzosamente una conexión existente.

Descubrí por parte de un administrador que el grupo de aplicaciones de IIS que hospedaba el servicio web se reciclaba automáticamente después de quedarse sin memoria. El error en el cliente ocurrió cuando el grupo de aplicaciones se recicló.

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

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 al hecho de que el certificado del servidor no está configurado correctamente con HTTP.SYS en el caso 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ó forzosamente una conexión existente.

¡Nuestra licencia del proxy bluecoat ha expirado! por lo que no fue posible llegar a la parte externa (internet).

Si está utilizando el modo de transferencia = transmitido, intente cambiarlo a búfer.

Si este no es el problema, podrías publicar tu configuración.

Tenía 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 revisar todo en código y configuración, parece que el mensaje de error no es tan engañoso como las excepciones internas, por lo que después de una comprobación rápida descubrimos que el puerto 443 estaba enganchado por skype (en el servidor de desarrollo). Te recomiendo que eches un vistazo a lo que contiene la solicitud (Fiddler podría ayudar aquí) y asegúrate de que puedes llegar al frente del servicio (ver el archivo .svc en tu navegador) y sus metadatos.

Buena suerte.

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

Para confirmar esto, simplemente registré System.Net.ServicePointManager.SecurityProtocol antes 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, Tls pero después de unas pocas solicitudes a los servidores proveedores originales esto cambió a Ssl3 y las solicitudes al servicio TLS dieron el error.

Para solucionarlo, simplemente hice lo que me 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 al ejecutar cuadros anteriores de XP SP3 contra IIS y Glassfish en Amazon AWS. Amazon cambió su configuración del equilibrador de carga predeterminado 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. Las cifras se pueden cambiar en ELB accediendo a la pestaña del oyente en la consola y haciendo clic en la cifra al lado del oyente en particular que está tratando de hacer funcionar.

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

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

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

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