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

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

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

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.

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

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"

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

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.

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 ).

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.

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'

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

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.

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"

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

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.

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).

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.