2011-10-18 12 views
20

Tengo un sitio web que estoy utilizando para albergar Redmine y varios repositorios GitSSL funciona con el navegador, wget, y el rizo, pero falla con git

Esto funciona perfectamente para http, pero no se puede clonar por https, es decir

git clone http://mysite.com/git/test.git 

funciona bien, pero

git clone https://mysite.com/git/test.git 

falla

lo extraño es que https parece funcionar para todo lo demás que he probado. Si abro

https://mysite.com/git/test.git 

en un navegador (probado en Chrome y Firefox), consigo errores ni advertencias. También puedo

curl https://mysite.com/git/test.git 
wget https://mysite.com/git/test.git 

que funcionan sin quejas ni advertencias.

Aquí está la salida detallada de git:

$ GIT_CURL_VERBOSE=1 git clone https://[email protected]/test/test.git 
Cloning into test... 
Password: 
* Couldn't find host mysite.com in the .netrc file; using defaults 
* About to connect() to mysite.com port 443 (#0) 
* Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0) 
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt 
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none 
* Closing connection #0 
* Couldn't find host mysite.com in the .netrc file; using defaults 
* About to connect() to mysite.com port 443 (#0) 
* Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0) 
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt 
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none 
* Closing connection #0 
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://user\ 
@mysite.com/test/test.git/info/refs 

fatal: HTTP request failed 

Aquí está la salida detallada de rizo, con la información personal cambió:

* About to connect() to mysite.com port 443 (#0) 
* Trying 127.0.0.1... connected 
* Connected to mysite.com (127.0.0.1) port 443 (#0) 
* successfully set certificate verify locations: 
* CAfile: none 
    CApath: /etc/ssl/certs 
* SSLv3, TLS handshake, Client hello (1): 
* SSLv3, TLS handshake, Server hello (2): 
* SSLv3, TLS handshake, CERT (11): 
* SSLv3, TLS handshake, Server key exchange (12): 
* SSLv3, TLS handshake, Server finished (14): 
* SSLv3, TLS handshake, Client key exchange (16): 
* SSLv3, TLS change cipher, Client hello (1): 
* SSLv3, TLS handshake, Finished (20): 
* SSLv3, TLS change cipher, Client hello (1): 
* SSLv3, TLS handshake, Finished (20): 
* SSL connection using DHE-RSA-AES256-SHA 
* Server certificate: 
*  subject: C=US; <... cut my certs info ...> 
*  start date: 2011-10-18 00:00:00 GMT 
*  expire date: 2013-10-17 23:59:59 GMT 
*  subjectAltName: mysite.com matched 
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO High-Assurance Secure Server CA 
*  SSL certificate verify ok. 
> GET/HTTP/1.1 
> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3 
> Host: mysite.com 
> Accept: */* 
> 
< HTTP/1.1 200 OK 
< Date: Tue, 18 Oct 2011 21:39:54 GMT 
< Server: Apache/2.2.14 (Ubuntu) 
< Last-Modified: Fri, 14 Oct 2011 03:20:01 GMT 
< ETag: "8209c-87-4af39bb89ccac" 
< Accept-Ranges: bytes 
< Content-Length: 135 
< Vary: Accept-Encoding 
< Content-Type: text/html 
< X-Pad: avoid browser bug 
< 
<p>Welcome to the mysite.com<p/> 
* Connection #0 to host mysite.com left intact 
* Closing connection #0 
* SSLv3, TLS alert, Client hello (1): 

La única diferencia que puedo ver es que git parece utilizar un CAfile explícito mientras curl utiliza todo el directorio? Soy nuevo en ssl (al menos en el lado de administración), así que no estoy seguro de lo que esto significa o cómo podría configurar git para que funcione de la misma manera que curl.

Estoy usando git 1.7.5.4 y apache 2.2.14 en Ubuntu 10.04. Intenté clonar desde 3 hosts diferentes de Linux (incluida otra cuenta en el servidor) y no funciona nada.

También he utilizado la herramienta openssl para verificar mi certificado en el servidor:

$openssl verify -purpose sslserver -CAfile chain.crt signed.pem 
signed.pem: OK 

Esto puede estar relacionado con el error https://bugs.maemo.org/show_bug.cgi?id=4953 pero parece diferente porque no estoy recibiendo ningún tipo de advertencia o errores en ninguno otro programa.

Vale la pena mencionar que estoy usando gitolite y redmine_git_hosting usando http inteligente para hacer la autenticación sobre https. No creo que nada de esto tenga la culpa, porque el problema existe incluso si simplemente incluyo un repositorio simple que funcione en/var/www y lo accedo directamente. Además, funciona git over ssh (con y sin gitolita).

Háganme saber si tiene alguna idea de lo que podría estar mal o si desea obtener más información. Realmente preferiría que SSL funcione correctamente, en lugar de forzar a todos a deshabilitar la comprobación de certificados en GIT, aunque esa es una solución actual.

¡Gracias por leer esta publicación larga!

+0

Tenga en cuenta que con Git 2.5+, usted será capaz de especificar una lista de cifrado para el enrollamiento de usar. Eso podría ayudar. ver http://stackoverflow.com/a/30442395/6309 – VonC

Respuesta

15

Resulta que se trataba de un problema de gnuTLS. gnuTLS es sensible a los pedidos, mientras que openssl no lo es. Reordené los certificados en mi archivo cert intermedio y el problema desapareció

+5

¿De qué archivo de certificado intermedio está hablando? ¿La cadena de certificados apache del lado del servidor o un archivo del lado del cliente? Si el segundo, ¿cuál? –

+0

Era el archivo de certificado intermedio del lado del servidor – stokastic

+0

Sé que esta es una pregunta antigua, pero estoy obteniendo una respuesta similar. ¿Puede proporcionar más detalles sobre cómo hacer esto? –

-1

exportación GIT_SSL_NO_VERIFY = 1

De http://blog.breadncup.com/2011/06/09/skip-git-ssl-verification/

ADVERTENCIA: ya que algunas personas han mencionado, esto desactiva la verificación, haciendo que se abra a un detective de problemas de seguridad.No debe confiar en ello a largo plazo, pero, en caso de apuro, hará el trabajo.

+4

Es como tener problemas para desbloquear puertas que se resuelven al dejar las puertas desbloqueadas todo el tiempo. Hay algunos riesgos de seguridad relacionados. –

+0

Esto no funciona para mí @ debian wheezy, git 1.7.10.4, todavía gnutls_handshake() falló :(. –

+0

Por favor, nunca hagas esto. Sin verificación, básicamente estás pidiendo a git que ponga malware en tu sistema. – Glyph

11

La respuesta de XCondE resolverá el problema, pero apagar las advertencias de seguridad siempre parece una mala idea. Si está ejecutando en un cuadro ubuntu, entonces el problema puede ser que el certificado CA para su servidor web no se encuentra en el archivo /etc/ssl/certs/ca-certificates.crt. Me encontré con esto con un servidor git alojado en un servidor web con un certificado SSL firmado por www.incommon.org.

Puedes añadir el certificado intermedio a su archivo ca-certificados, de la siguiente manera:

wget http://cert.incommon.org/InCommonServerCA.crt 
openssl x509 -inform DER -in InCommonServerCA.crt -out incommon.pem 
cat /etc/ssl/certs/ca-certificates.crt incommon.pem > ca-certs2.crt 
sudo cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak 
sudo cp ca-certs2.crt /etc/ssl/certs/ca-certificates.crt 

Hay una buena discusión de lo que está pasando detrás de las escenas aquí: http://curl.haxx.se/docs/sslcerts.html

2

Git utiliza gnutls de esto, que requiere que se especifique CA. Esto se puede hacer con per-repositorio con:

git config http.sslcapath <path to CA directory> 

O

git config http.sslcainfo <path to CA cert> 

También puede especificar --system o --global.

3

Encontré este error con uno de mis certificados Comodo PositiveSSL y pude solucionarlo cambiando el orden de los certificados intermedios.

Después de ordenar el certificado, que dieron con los siguientes archivos:

  • certificados raíz de CA - AddTrustExternalCARoot.crt
  • Intermedio Certificado CA - COMODORSAAddTrustCA.crt
  • Intermedio Certificado CA - COMODORSADomainValidationSecureServerCA.crt
  • Certificado comodín PositiveSSL - STAR_mydomain_com.crt

Originalmente, el orden de los certificados en el .crt estaba proporcionando a Nginx fue el siguiente:

  • PositiveSSL Certificado Comodín - STAR_mydomain_com.crt
  • certificado de CA intermedia - COMODORSAAddTrustCA.crt
  • certificado de CA intermedia - COMODORSADomainValidationSecureServerCA.crt

sin embargo, invierte el orden de los dos últimos certificados y Git ya no arroja errores de verificación.

Cuestiones relacionadas