2011-10-14 10 views
11

Hice mi propio servidor git en una distribución de centos. Puedo contactar al servidor a través del protocolo git en mi casa. Pero cuando intento acceder a través de https en la oficina obtengo:git problema a través de https: rutinas: SSL23_GET_SERVER_HELLO

Cloning into /Users/vito/Documents/... error: error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) while accessing https://[email protected]/vitorepo.git/info/refs

fatal: HTTP request failed

¿Dónde está el problema? En mi servidor o en mi oficina-mac?

+0

¿Su servidor git está realmente disponible fuera de la subred de su casa? ¿Puedes, por ejemplo, SSH hacerlo con éxito desde el trabajo? –

+0

sí. Mi servidor es un servidor público con todos los puertos útiles abiertos. – Vito

Respuesta

3

Parece que hay un problema de compatibilidad entre la versión anterior de OpenSSL (0.9.8) que actúa como cliente y la versión reciente de OpenSSL (1.0.0) que actúa como servidor con algunas opciones específicas utilizadas por Curl en el lado del cliente y Apache en el lado del servidor.

Probablemente se deba a una corrección de seguridad reciente en OpenSSL (probablemente la que está en contra de los ataques de degradación del protocolo).

Intente actualizar la versión de la biblioteca OpenSSL en el lado del cliente a la 1.0.0.

Ver:

https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976

1

Creo que esto es un nombre de host-a juego problema en el servidor. El error 1112 es SSL_R_TLSV1_UNRECOGNIZED_NAME y proviene de una discrepancia en el nombre SNI (info on SNI). Estaba teniendo el mismo issue in curl.

Para mí, el trabajo fue para asegurarme de que el nombre que utilicé en el cliente coincidía con una de las configuraciones ServerName o ServerAlias ​​en el servidor. Por supuesto, estos comandos son para un servidor apache; No sé lo que tienes que hacer para un servidor de git. Pero sospecho que los nombres de servidor que está usando desde el hogar y el trabajo son diferentes, y el nombre de la casa es el nombre canónico que está usando el servidor de git (y, por lo tanto, SNI está funcionando).

La corrección 'real' probablemente tomará un cambio de cliente en git para permitir una forma de ignorar la advertencia de desajuste de nombre (la forma en que su navegador ya lo hace).

7

Obtuve exactamente la misma respuesta de curl al intentar conectarme con una instancia de ubuntu que ejecuta openssl 1.0.0e. Resolví el problema satisfactoriamente agregando el indicador -ssl3 al comando curl.

+0

usted señor es un genio. Tenía que hacer esto desde os x. ¿Puedes explicar por qué esto funciona? –

2

En caso de que alguien tenga este problema con XMLRPC.

La respuesta de Daniel (forzando la versión 3 de SSL) me solucionó el problema. solo especifique XMLRPC_SSLVERSION_SSLv3 en las opciones clientXmlTransport_curl (C++).

El problema comenzó cuando actualizamos nuestro servidor a OpenSSL versión 1.0.1-4ubuntu5.5 y los clientes seguían ejecutando 0.9.8o-5ubuntu1.7.

1

No estoy seguro si tuve exactamente el mismo problema, pero el mensaje de error fue el mismo. Solo parecía estar sucediendo en el cuadro ubuntu en el que configuré un servidor git, por alguna razón el cents box con un servidor git configurado estaba bien.

Lo acabo de resolver después de 3 o 4 días. Resultó ser porque la biblioteca subyacente de Curl de git tiene una implementación interrumpida Keep-alive (terminé descargando el tráfico HTTP y verificando el comportamiento a mano).

En resumen Curl (al menos la versión utilizada en cada implementación de Git que pude encontrar, incluyendo git de línea de comando y EGit de eclipse) no parece interpretar correctamente el encabezado de respuesta de conexión, o más correctamente no parece interpretar correctamente la ausencia de ella.

Para solucionar el problema, debe configurar el servidor virtual SSL dentro del apache que está sirviendo su repositorio GIT con una directiva adicional específica para git. Agregue estas líneas justo antes del </VirtualHost >.

BrowserMatch "git" nokeepalive ssl-unclean-shutdown 

Usted lamentablemente no se puede decir que Apache acaba de rebajar a HTTP/1.0 (sería más limpia) porque Curl no puede manejar eso, sino que puede simplemente decir que para forzar un Connection: close en cada petición cuales Curl no sabe cómo manejarlo.

En una coincidencia engañosa, si intenta probar Curl directamente sin este cambio, parecerá que funciona, porque hace una sola solicitud y luego aborta. Solo haciendo que curl ejecute dos solicitudes en la misma conexión keep-alive sobre ssl, este problema se hará evidente.

0

Tuve el mismo error. La causa raíz parece ser la incompatibilidad de las versiones de cliente/servidor openssl. He actualizado mi servidor con apt-get upgrade openssl y actualicé mi instalación de Windows Git.

La combinación de ventanas git cliente git version 1.9.4.msysgit.0, que contiene la versión de OpenSSL: OpenSSL 0.9.8e 23 Feb 2007

y el servidor con la versión de OpenSSL: OpenSSL 1.0.1c 10 May 2012

parece funcionar bien juntos.

Cuestiones relacionadas