2011-10-18 9 views
20

Ho un sito web che sto usando per ospitare Redmine e diversi repository gitSSL funziona con il browser, wget, e riccio, ma non riesce con git

Questo funziona perfettamente per http, ma non riesco a clonare con https, cioè

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

funziona bene, ma

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

fallisce

La cosa strana è che https sembra funzionare per tutto il resto che ho testato. Se apro

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

in un browser (testato in chrome e firefox), non ottengo errori o avvisi. Posso anche

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

entrambi funzionano senza lamentele o avvisi.

Ecco l'output dettagliato da 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 

Ecco l'output dettagliato da riccio, con le informazioni personali cambiato:

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

L'unica differenza che posso vedere è che git sembra usare un CAfile esplicito mentre curl usa l'intera directory? Sono nuovo di ssl (almeno sul lato admin), quindi non sono sicuro di cosa significhi o di come potrei configurare git per funzionare allo stesso modo di curl.

Sto usando git 1.7.5.4 e apache 2.2.14 su Ubuntu 10.04. Ho provato a clonare da 3 diversi host Linux (incluso un altro account sul server stesso), e niente funziona.

Ho anche usato il tool OpenSSL per verificare il mio cert sul server:

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

Questo può essere correlato al bug https://bugs.maemo.org/show_bug.cgi?id=4953 ma sembra diverso perché non ricevo alcun avviso o errori in qualsiasi altro programma.

Vale la pena ricordare che sto utilizzando gitolite e redmine_git_hosting utilizzando http per eseguire l'autenticazione tramite https. Non penso che nulla di tutto questo sia comunque in colpa, perché il problema esiste anche se mi metto un repository nudo in altrimenti funzionamento in/var/www e lo accedo direttamente. Inoltre, git over ssh (con e senza gitolite) funziona.

Per favore fatemi sapere se avete qualche idea su cosa potrebbe essere sbagliato o se desiderate ulteriori informazioni. Preferirei davvero che lo ssl funzioni correttamente, invece di forzare tutti a disabilitare il controllo dei certificati in git, anche se questa è una soluzione alternativa.

Grazie per aver letto questo lungo post!

+0

Si noti che con Git 2.5+, si sarà in grado di specificare un elenco di cifratura per curl per usare. Questo potrebbe aiutare. vedi http://stackoverflow.com/a/30442395/6309 – VonC

risposta

15

Si è scoperto che si trattava di un problema di gnuTLS. gnuTLS è sensibile agli ordini, mentre openssl no. Ho riordinato i certificati nel mio file cert intermedio e il problema è andato via

+5

Di quale file cert intermedio stai parlando? La catena di sicurezza Apache lato server o un file lato client? Se il secondo, quale? –

+0

Era il file di certificato intermedio sul lato server – stokastic

+0

So che questa è una domanda vecchia, ma sto ottenendo una risposta simile. Potete fornire maggiori dettagli su come farlo? –

-1

export GIT_SSL_NO_VERIFY = 1

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

ATTENZIONE: come alcune persone menzionati, questo disabilita la verifica, lasciando che si apre ad un segugio di problemi di sicurezza.Non dovresti fare affidamento su di esso a lungo termine ma, in un pizzico, finirà il lavoro.

+4

È come avere problemi con lo sblocco delle porte che vengono risolti lasciando le porte sbloccate per tutto il tempo. Esistono alcuni rischi relativi alla sicurezza. –

+0

Questo non funziona per me @ debian wheezy, git 1.7.10.4, ancora gnutls_handshake() non riuscito :(. –

+0

Si prega di non farlo mai. Senza la verifica si sta praticamente chiedendo a git di inserire malware sul proprio sistema. – Glyph

11

La risposta di XCondE risolverà il problema, ma disattivare gli avvisi di sicurezza sembra sempre una cattiva idea. Se stai usando una finestra Ubuntu, il problema potrebbe essere che il certificato CA per il tuo server web non si trova nel file /etc/ssl/certs/ca-certificates.crt. Mi sono imbattuto in questo con un server git ospitato su un server web con un certificato SSL firmato da www.incommon.org.

È possibile aggiungere il certificato intermedio al file ca-certificates, come segue:

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 

C'è una buona discussione di quello che sta succedendo dietro le quinte qui: http://curl.haxx.se/docs/sslcerts.html

2

git utilizza gnutls per questa roba, che richiede che la CA sia specificata. Questo può essere fatto con per-respository con:

git config http.sslcapath <path to CA directory> 

O

git config http.sslcainfo <path to CA cert> 

è anche possibile specificare --system o --global.

3

Ho riscontrato questo errore con uno dei miei certificati Comodo PositiveSSL e ho potuto correggerlo cambiando l'ordine dei certificati intermedi.

Dopo aver ordinato il certificato, mi è stato fornito con i seguenti file:

  • Root CA Certificate - AddTrustExternalCARoot.crt
  • Intermedio Certificato CA - COMODORSAAddTrustCA.crt
  • Intermedio Certificato CA - COMODORSADomainValidationSecureServerCA.crt
  • PositiveSSL Wildcard Certificate - STAR_mydomain_com.crt

In origine, l'ordine dei certificati nel .crt mi stava fornendo a Nginx è stato il seguente:

  • PositiveSSL certificato con caratteri jolly - STAR_mydomain_com.crt
  • Intermedio Certificato CA - COMODORSAAddTrustCA.crt
  • Intermedio Certificato CA - COMODORSADomainValidationSecureServerCA.crt

Tuttavia, ho annullato l'ordine degli ultimi due certificati e Git non genera più errori di verifica.

Problemi correlati