la vérification du certificat du serveur a échoué. Fichier CA: /etc/ssl/certs/ca-certificates.crt Fichier CRL: aucun

335

Je peux pousser par projet de clonage à l'aide de ssh, mais cela ne fonctionne pas lorsque je clone un projet avec https.

Le message d'erreur qui me montre est:

server certificate verification failed. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none

certificate ssl-certificate gitlab

— Sokhom Ratanak
source

422

TLDR:

hostname=XXX
port=443
trust_cert_file_location=`curl-config --ca`

sudo bash -c "echo -n | openssl s_client -showcerts -connect $hostname:$port -servername $hostname \
    2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  \
    >> $trust_cert_file_location"

Longue réponse

La raison principale est que votre ordinateur ne fait pas confiance à l' autorité de certification qui a signé le certificat utilisé sur le serveur Gitlab . Cela ne signifie pas que le certificat est suspect, mais il peut être auto-signé ou signé par une institution / entreprise qui ne figure pas dans la liste des autorités de certification de votre système d'exploitation. Ce que vous devez faire pour contourner le problème sur votre ordinateur c'est lui dire de faire confiance à ce certificat - si vous n'avez aucune raison de vous en méfier.

Vous devez vérifier le certificat Web utilisé pour votre serveur gitLab et l'ajouter à votre </git_installation_folder>/bin/curl-ca-bundle.crt.

Pour vérifier si au moins le clone fonctionne sans vérifier ledit certificat, vous pouvez définir:

export GIT_SSL_NO_VERIFY=1
#or
git config --global http.sslverify false

Mais ce ne serait que pour les tests, comme illustré dans « SSL fonctionne avec le navigateur, wget et curl, mais échoue avec git », ou dans cet article de blog .

Vérifiez vos paramètres GitLab, un problème 4272 .

Pour obtenir ce certificat (que vous devrez ajouter à votre curl-ca-bundle.crtfichier), tapez a:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

(' yourserver.com' étant le nom de votre serveur GitLab, et il YourHttpsGitlabPorts'agit généralement du port https 443)

Pour vérifier l'autorité de certification (émetteur de l'autorité de certification), tapez a:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGilabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | openssl x509 -noout -text | grep "CA Issuers" | head -1

Remarque: Valeriy Katkov suggère dans les commentaires d'ajouter une -servernameoption à la commande openssl, sinon la commande ne montre pas de certificat pour www.github.com dans le cas de Valeriy.

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Findekano ajoute dans les commentaires :

pour identifier l'emplacement curl-ca-bundle.crt, vous pouvez utiliser la commande

curl-config --ca

Consultez également ma réponse la plus récente " github: la vérification du certificat du serveur a échoué ": vous devrez peut-être renommer ces certificats:

sudo apt-get install --reinstall ca-certificates
sudo mkdir /usr/local/share/ca-certificates/cacert.org
sudo wget -P /usr/local/share/ca-certificates/cacert.org http://www.cacert.org/certs/root.crt http://www.cacert.org/certs/class3.crt
sudo update-ca-certificates
git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt

— VonC
source

8

Le message d'origine n'indique-t-il pas où ajouter le certificat? Dans mon cas curl-config --caretourné /etc/ssl/certs/ca-certificates.crt, c'est là que j'ai dû ajouter le certificat. En dehors de cela, cette réponse a été la première information me pointant dans la bonne direction avec ce problème

— uli_1973

1

Comment trouvez-vous le dossier d'installation de git?

— Bhargav

1

@Bhargav, cela dépend de votre système d'exploitation. Sous Linux, vous pouvez faire un which git.

— VonC

3

J'ai couru curl-config --ca, mais rien n'a été retourné.

— Fernando Costa

1

Merci pour le conseil - vous m'avez sauvé la journée.

— Janne

221

Remarque: cela a des implications de sécurité majeures .

Ouvrez votre terminal et exécutez la commande suivante:

export GIT_SSL_NO_VERIFY=1

Cela fonctionne pour moi et j'utilise le système Linux.

— Afzal Masood
source

60

Pas de downvoting car c'est une solution de contournement lorsque vous savez ce que vous faites. Cependant, déconseille fortement cela dans le cas général.

— tripleee

9

Je ne dirais pas que c'est une solution de contournement lorsque vous savez ce que vous faites. Lorsque vous savez ce que vous faites, vous devriez regarder un certificat qui échoue car "peut-être que quelqu'un nous a piraté" et non "eh bien la sécurité dit que quelqu'un nous a piraté, devinez que nous devons désactiver la sécurité." C'est au mieux une mesure provisoire si quelque chose doit être poussé dès que possible.

— srcspider

1

en exportant au-dessus du drapeau, j'obtiens en dessous de error.error: RPC a échoué; résultat = 22, code HTTP = 403 fatal: l'extrémité distante a raccroché de façon inattendue erreur: RPC a échoué; result = 22, code HTTP = 403 fatal: l'extrémité distante a raccroché de façon inattendue

— Desu

9

Seulement travaillé pour moi avecgit config --global http.sslverify false

— Dinei

2

Génial. Tu m'as fait gagner du temps.

— Sai prateek

146

Une autre cause de ce problème peut être que votre horloge est peut-être éteinte. Les certificats sont sensibles au temps.

Pour vérifier l'heure actuelle du système:

date -R

Vous pouvez envisager d'installer NTP pour synchroniser automatiquement l'heure du système avec les serveurs de temps Internet approuvés à partir du pool NTP global . Par exemple, pour installer sur Debian / Ubuntu:

apt-get install ntp

— davidthings
source

5

C'était mon problème. Mon université bloquait les paquets ntp, ce qui empêchait mon système de mettre à jour l'heure. Une fois que j'ai configuré les serveurs ntp de l'université, les choses fonctionnaient à nouveau. Merci pour cette astuce!

— Kyle

3

C'était aussi la cause de mon problème, j'utilisais un appareil embarqué qui avait une mauvaise date!

— Shervin Emami

C'était mon problème, avec les certificats. J'ai passé des heures à examiner toutes sortes de solutions avant de découvrir que le problème était l'horloge du serveur réglée dans le futur. Cela ne m'a pas aidé à obtenir une future version de Node.js, cependant. :-(

— Kevin Teljeur

1

@Katu ce n'est pas gitdit, c'est l'échange SSL sous-jacent. Git est construit avec le support SSL.

— Yvan

1

Je voterais ce 10000 fois .... ont cherché pourquoi cela ne fonctionnait pas depuis 6 heures entières maintenant ... Le serveur était éteint de moins de 7 minutes et cela a fait l'affaire ... MERCI!

— dGo

66

Si vous utilisez un serveur git dans un réseau privé et utilisez un certificat auto-signé ou un certificat sur une adresse IP; vous pouvez également simplement utiliser la configuration globale de git pour désactiver les vérifications SSL:

git config --global http.sslverify "false"

— Romain VDK
source

43

Eu le même problème. Causé par une autorité de certification auto-émise. Résolu en ajoutant un fichier .pem à / usr / local / share / ca-certificats / et en appelant

sudo update-ca-certificates

PS: le fichier pem dans le dossier ./share/ca-certificates DOIT avoir l'extension .crt

— Nikolay Ruban
source

2

Fonctionné comme un charme dans Linux

— Mint

voulez-vous dire cert.pem ou cert.crt ou cert.pem.crt?

— Moses Liao GZ

1

cert.pem devrait être renommé cert.pem.crt

— Nikolay Ruban

34

Vérifiez votre horloge système,

$ date

Si ce n'est pas le cas, la vérification du certificat échouera. Pour corriger l'horloge système,

$ apt-get install ntp

L'horloge doit se synchroniser.

Enfin, entrez à nouveau la commande clone.

— mycowan
source

1

Oui! J'ai eu une instance d'Ubuntu suspendue dans VirtualBox pendant longtemps. L'horloge système ne s'est pas synchronisée pour une raison quelconque lorsque je n'ai pas suspendu. La réponse de VonC semble bien informée, mais je suis vraiment content de ne pas avoir eu à exécuter un tas de commandes de sécurité que je ne comprends pas. Vérifiez ceci en premier!

— AndyJost

24

GIT_CURL_VERBOSE=1 git [clone|fetch]…

devrait vous dire où est le problème. Dans mon cas, cela était dû au fait que cURL ne prend pas en charge les certificats PEM lorsqu'il est construit contre NSS, car ce support n'est pas la ligne principale dans NSS ( # 726116 # 804215 # 402712 et plus ).

— Tobu
source

4

Belle addition avec le GIT_CURL_VERBOSE. Je ne l'ai pas mentionné dans ma réponse. +1

— VonC

18

Ou exécutez simplement ce commentaire pour ajouter le certificat du serveur à votre base de données:

echo $(echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort 2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p') >> /etc/ssl/certs/ca-certificates.crt

Ensuite, faites à nouveau git clone.

— phiphu
source

1

Je ne sais pas si cela fonctionne pour n'importe qui mais j'ai besoin de "tee" pour ajouter le fichier cert en tant que root: echo -n | openssl s_client -showcerts -connect yourserver.com:443 2> / dev / null | CERTIFICAT sed -ne '/ -BEGIN - /, / - CERTIFICAT FINAL- / p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt

— ywu

Dans mon cas, le serveur a un certificat valide, mais ma base de données ne l'inclut pas, avec cette commande j'ai résolu mais je dois dire que cette commande doit être exécutée avec les privilèges root.

— hermeslm

10

J'ai foiré mes fichiers CA pendant que je configure le proxy goagent. Impossible d'extraire des données de github et obtenez le même avertissement:

la vérification du certificat du serveur a échoué. Fichier CA: /etc/ssl/certs/ca-certificates.crt Fichier CRL: aucun

utilisez la méthode de Vonc, récupérez le certificat de github et placez-le dans /etc/ssl/certs/ca-certificates.crt, problème résolu.

echo -n | openssl s_client -showcerts -connect github.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p'

— IFQ
source

8

il n'est pas nécessaire de définir la vérification git ssl sur false. Cela se produit lorsque le système ne dispose pas de tous les certificats d'autorité CA. Surtout les gens qui ont un véritable certificat SSL manquant le certificat intermédiaire.

Il suffit d'ajouter le texte complet du certificat intermédiaire (toute la chaîne de l'autorité de certification et du certificat intermédiaire manquants) à

sudo gedit /etc/ssl/certs/ca-certificates.crt

fonctionne sans exécuter le update-ca-certificates.

Il en va de même pour les certificats générés manuellement, ajoutez simplement le texte du certificat CA.

À la fin: Push réussi: tout est à jour

— abcdef12
source

1

La même chose peut être causée si le serveur n'est pas configuré correctement avec toutes les chaînes d'autorité de certification SSL.

— abcdef12

Les problèmes de chaîne peuvent être la cause, comme l'a commenté abcdef12. J'ai eu ce problème avec git 1.9.1 - le serveur envoyait la chaîne de certificats: # 0 server cert; # 1 serveur cert (encore); # 2 cert. Signataire Le doublon dans la chaîne était la raison pour laquelle git ne l'aimait pas.

— jah

8

Ce que j'ai fait pour résoudre ce problème dans le terminal (Ubuntu 18.04):

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

J'ai obtenu deux morceaux de morceaux de certificat. Et j'ai copié les morceaux de certificat dans mon fichier de certificat /etc/ssl/certs/ca-certificates.crt.

— mindcoder
source

Cette solution résout mon problème identique dans Ubuntu 16.04.

— user3072843

Que voulez-vous dire exactement avec des morceaux de certificat ? Le bloc entre ---BEGIN CERTIFICATE---et --- END CERTIFICATE ---?

— B - rian

3

J'ai installé Xubuntu sur un Raspberry pi 2, j'ai trouvé le même problème avec le temps, car la synchronisation NTP et automatique du serveur était désactivée (ou non installée). Obtenez NTP

sudo apt-get install ntp

et changez "Heure et date" de "Manuel" en "Restez synchronisé avec les serveurs Internet"

— user273711
source

1

Finalement, ajoutez le http.sslverify à votre .git / config.

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://server/user/project.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[http]
        sslVerify = false

— Mickael L
source

1

Mieux vaut utiliser la ligne de commande git config http.sslVerify false. Suggérez-vous de modifier la configuration de Git par référentiel, et non globalement comme le suggère @ romain-vdk?

— ahogen

1

La première chose que vous devez vérifier est l'autorisation de fichier de /etc/sslet /etc/ssl/certs.

J'ai fait l'erreur de supprimer les autorisations de fichiers (ou de supprimer les rm -rf /etc/ssl/*répertoires SSL ) lors de l'utilisation du ssl-certnom / ID de groupe tout en travaillant sur mon outil de gestion de l'autorité de certification .

Ce fut alors que j'ai remarqué exactement le même message d'erreur wgetet des curloutils de navigateur CLI:

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Une fois que j'ai apporté l' autorisation de fichier /etc/sslet les /etc/ssl/certrépertoires o+rx-w, ces outils de navigateur CLI ont commencé à respirer un peu plus facilement:

mkdir -p /etc/ssl/certs
chmod u+rwx,go+rx /etc/ssl /etc/ssl/certs

J'ai également dû recréer le sous-répertoire Java et reconstruire les répertoires des certificats de l'autorité de certification de confiance:

mkdir /etc/ssl/certs/java
chmod u+rwx,go+rx /etc/ssl/certs/java
update-ca-certificates

et la côte était claire.

— John Greene
source

0

Je viens de rencontrer le même problème avec un dépôt git qui fonctionne toujours pour moi. Le problème était que j'y accédais via un accès WiFi public, qui redirige vers un portail captif lors de la première connexion (par exemple pour diffuser des annonces et accepter les tos).

— Tosha
source

0

Faites copier le certificat et l'ensemble dans un fichier .crt et assurez-vous qu'il y a une ligne vide entre les certificats dans le fichier.

Cela a fonctionné pour moi sur un serveur GitLab après avoir tout essayé sur Internet.

— shambhu
source