web-dev-qa-db-fra.com

SSL fonctionne avec browser, wget et curl, mais échoue avec git

J'ai un site Web que j'utilise pour héberger Redmine et plusieurs dépôts git

Cela fonctionne parfaitement pour http, mais je ne peux pas cloner avec https, c.-à-d.

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

fonctionne bien, mais

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

échoue

La chose étrange est que https semble fonctionner pour tout ce que j'ai testé. Si j'ouvre 

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

dans un navigateur (testé sous chrome et firefox), je n’obtiens aucune erreur ni aucun avertissement. je peux aussi 

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

les deux fonctionnent sans plaintes ni avertissements.

Voici la sortie commentée 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

Voici le résultat détaillé de curl, avec les informations personnelles modifiées:

* 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 seule différence que je peux voir est que git semble utiliser un fichier CA explicite tandis que curl utilise tout le répertoire? Je suis nouveau sur ssl (au moins du côté de l’administrateur), donc je ne suis pas sûr de ce que cela signifie ou de la façon dont je pourrais configurer git pour qu’il fonctionne de la même manière que curl.

J'utilise git 1.7.5.4 et Apache 2.2.14 sur Ubuntu 10.04. J'ai essayé de cloner 3 hôtes Linux différents (y compris un autre compte sur le serveur lui-même), et rien ne fonctionne.

J'ai également utilisé l'outil openssl pour vérifier mon certificat sur le serveur:

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

Cela peut être lié au bogue https://bugs.maemo.org/show_bug.cgi?id=4953 mais cela semble différent car je ne reçois aucun avertissement ni aucune erreur dans aucun autre programme.

Il est à noter que j'utilise gitolite et redmine_git_hosting en utilisant smart http pour l'authentification via https. Cependant, je ne pense pas que tout cela soit à blâmer, car le problème existe même si je mets juste un référentiel nu fonctionnant autrement dans/var/www et que je l’accède directement. En outre, git over ssh (avec et sans gitolite) fonctionne.

S'il vous plaît laissez-moi savoir si vous avez une idée de ce qui pourrait ne pas être correct ou si vous souhaitez plus d'informations. Je préférerais vraiment que SSL fonctionne correctement, au lieu d'obliger tout le monde à désactiver la vérification des certificats in git, bien qu'il s'agisse d'une solution de contournement actuelle.

Merci d'avoir lu ce long post!

22
stokastic

Il s’avère que c’est un problème lié à gnuTLS. gnuTLS est sensible à la commande, contrairement à openssl. J'ai re-commandé les certificats dans mon fichier de certification intermédiaire et le problème a disparu

17
stokastic

La réponse de XCondE résoudra le problème, mais désactiver les avertissements de sécurité semble toujours être une mauvaise idée. Si vous utilisez une boîte ubuntu, le problème peut être que le certificat de l'autorité de certification de votre serveur Web ne se trouve pas dans le fichier /etc/ssl/certs/ca-certificates.crt. J'ai rencontré ce problème avec un serveur git hébergé sur un serveur Web avec un certificat SSL signé par www.incommon.org.

Vous pouvez ajouter le certificat intermédiaire à votre fichier ca-certificates comme suit:

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

Il y a une bonne discussion sur ce qui se passe dans les coulisses ici: http://curl.haxx.se/docs/sslcerts.html

11
Pete Clark

J'ai rencontré cette erreur avec l'un de mes certificats Comodo PositiveSSL et j'ai pu y remédier en modifiant l'ordre des certificats intermédiaires.

Après avoir commandé le certificat, on m'a fourni les fichiers suivants:

  • Certificat d'autorité de certification racine - AddTrustExternalCARoot.crt
  • Certificat d'AC intermédiaire - COMODORSAAddTrustCA.crt
  • Certificat d'autorité de certification intermédiaire - COMODORSADomainValidationSecureServerCA.crt
  • Certificat positif de caractère générique - STAR_mydomain_com.crt

À l'origine, l'ordre des certificats dans le .crt que je fournissais à Nginx était le suivant:

  • Certificat positif de caractère générique - STAR_mydomain_com.crt
  • Certificat d'AC intermédiaire - COMODORSAAddTrustCA.crt
  • Certificat d'autorité de certification intermédiaire - COMODORSADomainValidationSecureServerCA.crt

Cependant, j'ai inversé l'ordre des deux derniers certificats et Git ne génère plus d'erreur de vérification.

4
Nathan Osman

git utilise gnutls pour ce genre de choses, ce qui nécessite que l’AC soit spécifiée. Cela peut être fait avec chaque référentiel avec:

git config http.sslcapath <path to CA directory>

OR

git config http.sslcainfo <path to CA cert>

Vous pouvez également spécifier --system ou --global.

2
Jonathan Wiepert

export GIT_SSL_NO_VERIFY = 1

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

AVERTISSEMENT: comme certaines personnes l’ont mentionné, cela désactive la vérification, ce qui vous laisse exposé à de nombreux problèmes de sécurité. Vous ne devriez pas vous y fier à long terme, mais, à la rigueur, le travail sera fait.

0
Thiago Figueiro

Le problème peut être que vous n'avez pas configuré correctement Apache

Vous devrez peut-être ajouter votre nom de serveur au fichier de configuration Apache /Etc/Apache2/sites-enabled/default-ssl.conf, par exemple:

ServerName demo.personalserver.com

De: https://www.progclub.org/blog/2014/09/03/gnutls_handshake-failed-using-git/#comment-96924

0
FrankPak