2010-12-22 13 views
11

Tengo una aplicación de Windows C (.Net 3.0 Framework) que realiza una llamada al servicio web PHP utilizando HttpWebRequest.HttpWebRequest.GetRequestStream() se rompe por tiempo de espera en la conexión SSL en Windows 7/Vista

En Win 7 & Vista, si la llamada se realiza a través de no SSL (es decir http://), el código funciona bien. Cuando se cambia la llamada para llamar a la versión SSL (https :) del enlace, se agota en HttpWebRequest.GetRequestStream(). Esto sucede todo el tiempo.

Cuando esta misma aplicación se ejecuta en una máquina Windows XP, funciona bien con la URL HTTP o HTTPS que se utiliza.

El código tiene el código aceptar todos los certificados de servidor. Además, he agregado System.Net logging. Graba el registro, pero como los paquetes están encriptados, realmente no se ve mucho, excepto por la declaración de interrupción de tiempo de espera.

También he probado Fiddler, pero de nuevo con los paquetes encriptados, no veo mucho. Por cierto, cuando trato de usar Fiddler2 para descifrar la aplicación se cuelga, por lo que no ha sido exitoso.

De todos modos, cualquier ayuda sería apreciada. Gracias.

voy a añadir:

  • puedo telnet en el puerto
  • he intentado ejecutar la aplicación como administrador
  • He probado el (cualquier cosa que trate) modo de compatibilidad con Win XP
  • I ha seleccionado el código de conexión en una aplicación independiente simple
+0

¿Se puede pegar el logil que muestra el tiempo de espera en pastebin.com? – feroze

Respuesta

9

Este error apareció en una aplicación C# activa después de migrar el sitio web al que se accede a un nuevo servidor, y eso indicaba un problema en el servidor. De hecho, finalmente resolvimos este problema al establecer el valor "ServerName" en el archivo de configuración de Apache para que coincida con el nombre de dominio registrado en el certificado. (. Otro foro mencionó que el establecimiento de "ServerAlias" también funcionaría)

Más específicamente, el archivo httpd.conf para el sitio SSL tenían el siguiente en la sección VirtualHost:

ServerName www.secure.mydomain.com 

El certificado se registró a secure.mydomain.com, y la URL a la que accedíamos también era https://secure.mydomain.com/test.html.

Así que simplemente cambiando el archivo de configuración a la siguiente y reiniciar Apache hizo el truco:

ServerName secure.mydomain.com 

La siguiente tendría también trabajó, lo más probable:

ServerName www.secure.mydomain.com 
ServerAlias secure.mydomain.com 

He aquí algunos adicional información de fondo, para futura referencia:

Los dos errores que vimos en t el Sistema.Net.trace.log fueron:

System.Net.Sockets Error: 0 : [4316] Exception in the 
    Socket#18796293::Receive - A blocking operation was 
    interrupted by a call to WSACancelBlockingCall 
System.Net Error: 0 : [4316] Exception in the 
    HttpWebRequest#35191196:: - The operation has timed out 

Aquí están todas las cosas que intentamos que no resuelven el problema:

  • la instalación de certificados intermedios desde el emisor del certificado SSL en Apache (esto es necesario)
  • cambio de agente de usuario en la solicitud web (sin efecto)
  • cambiantes del lado del servidor y del lado del cliente tiempos de espera y los límites de memoria (sin efecto)
  • de prueba con una página estática (sin efec t)
  • prueba con otros sitios https (que funcionaba bien)
  • añadir el certificado al almacén de certificados de confianza (sin efecto)
  • adquirir e instalar un certificado de una entidad emisora ​​de certificados diferente (sin efecto)
  • comparar los archivos .conf de host virtual desde un servidor que funciona conocido al servidor problemático (esto nos llevó a resolver el problema)

La URL https se puede abrir en Opera, IE8 y Firefox sin ningún problema. WGET para Windows se quejó de un certificado no válido, pero una vez más, WGET es una aplicación antigua y no parece confiar en tantos certificados.

La aplicación de cliente C# funcionaba con Windows XP, pero no con Windows 7 o Windows Vista. Parece que Windows 7 y Vista son más agresivos para validar el certificado. No proporcionan un mensaje de error informativo cuando falla y, en su lugar, simplemente exceden el tiempo de espera durante el protocolo de enlace SSL.

+0

Gracias por publicar la resolución al problema de Shailesh. No había tenido la oportunidad de actualizarlo todavía. –

+0

Esto estaba justo en el dinero. Qué mensaje de error terriblemente engañoso. –

+0

Gracias por esta respuesta, resolvió lo que fue un problema muy desconcertante para nosotros. Teníamos máquinas actualizadas con Windows Update cuyos programas .NET se agotaban al contactar al servidor web. Las máquinas que no se habían actualizado desde antes (aproximadamente) en julio de 2012 funcionaban bien. Entonces, hay una actualización de Windows que modifica el comportamiento en algún momento de este período. La solución del problema 'ServerName' en el servidor web Apache resolvió el problema para nosotros. –

0

Quizás el certificado SSL se refiere a un CRL que tiene una ¿Cuánto tiempo buscar?

+0

Puede deshabilitar la comprobación de CRL. Establezca ServicePointManager.CheckCertificateRevocationList = false. Además, si usa wireshark, puede ver si el tiempo de espera se debe a CRL u otra cosa por completo. Si publicas el registro de system.net en pastebin, también puedo echarle un vistazo. – feroze

+0

Gracias por los comentarios, chicos. Lo aprecio. Shailesh (humbads) y yo lo rastreamos hasta ser un problema de configuración de certificado en el servidor. La respuesta es arriba. ¡Gracias de nuevo! –

Cuestiones relacionadas