la vérification du certificat de serveur a échoué. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfichier: aucun
Je peux utiliser un projet de clonage en utilisant ssh, mais cela ne fonctionne pas lorsque je clone un projet avec https. il montre une erreur de message comme ci-dessous.
server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.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 \
2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
>> $trust_cert_file_location"
Réponse longue
La raison fondamentale 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 ne figurant 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 douter.
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 les navigateurs navigateur, wget et curl, mais échoue avec git ", ou dans ce article de blog .
Vérifiez vos paramètres GitLab, a in issue 4272 .
Pour obtenir ce certificat (que vous devez ajouter à votre fichier curl-ca-bundle.crt]), tapez un:
echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort \
2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
(avec 'yourserver.com' comme nom de votre serveur GitLab)
Pour vérifier l'autorité de certification (émetteur de l'autorité de certification), tapez:
echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort \
2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
| openssl x509 -noout -text | grep "CA Issuers" | head -1
Note: Valeriy Katkov suggère dans les commentaires d'ajouter l'option -servername à la commande openssl, sinon la commande n'est pas affichée 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 de
curl-ca-bundle.crt, vous pouvez utiliser la commande
curl-config --ca
Voir aussi ma réponse plus récente " github: la vérification du certificat de 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
Note: Ceci a majeur implications pour la sécurité.
Ouvrez votre terminal et lancez la commande suivante:
export GIT_SSL_NO_VERIFY=1
Cela fonctionne pour moi et j'utilise un 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 pourriez envisager d’installer NTP pour synchroniser automatiquement l’heure système avec des serveurs de temps Internet sécurisés du groupe pool global NTP . 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 aussi simplement utiliser la configuration globale de git pour désactiver les vérifications ssl:
git config --global http.sslverify "false"
J'ai eu le même problème. Causé par une autorité de certification auto-émise. Résolu en ajoutant le fichier .pem à / usr/local/share/ca-certificates / et en appelant
Sudo update-ca-certificates
PS: le fichier pem du dossier ./share/ca-certificates DOIT avoir une extension .crt
Vérifiez votre horloge système,
$ date
Si ce n'est pas correct, la vérification du certificat échouera. Pour corriger l'horloge du système,
$ apt-get install ntp
L'horloge devrait se synchroniser.
Enfin, entrez à nouveau la commande de clonage.
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 prenait pas en charge les certificats PEM lorsqu’il était construit sur NSS, du fait que cette prise en charge n’était pas principale dans NSS ( # 726116# 804215# 402712etplus ).
Ou simplement, lancez ce commentaire pour ajouter le certificat de 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.
Je me suis planté avec mes fichiers de CA pendant la configuration du proxy goagent. Impossible d'extraire les données de github et d'obtenir le même avertissement:
la vérification du certificat de serveur a échoué. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfichier: aucun
utilisez la méthode de Vonc, récupérez le certificat auprès de github et mettez-le dans /etc/ssl/certs/ca-certificates.crt, le problème est résolu.
echo -n | openssl s_client -showcerts -connect github.com:443 2>/dev/null | sed -ne '/ -BEGIN CERTIFICATE - /,/- CERTIFICAT DE FIN-/p'
il n'est pas nécessaire de définir la vérification de git ssl sur false. Cela est dû au fait que le système ne dispose pas de tous les certificats d'autorité de certification. Généralement, les personnes qui possèdent un certificat SSL authentique ne possèdent pas le certificat intermédiaire.
Il suffit d’ajouter le texte complet du certificat intermédiaire (chaîne complète de certificats d’autorité de certification et intermédiaires 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 de l'autorité de certification.
À la fin: Pousser avec succès: tout est à jour
J'ai installé Xubuntu sur un Raspberry Pi 2, j'ai rencontré le même problème avec le temps que NTP et la synchronisation automatique du serveur était désactivée (ou non installée). Obtenir NTP
Sudo apt-get install ntp
et remplacez "Manuel" par "Heure et date" par "Rester synchronisé avec les serveurs Internet"
Ajoutez éventuellement le fichier http.sslverify à votre fichier .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
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 deux morceaux de morceaux de certificat. Et j'ai copié les fragments de certificat dans mon fichier de certificat dans /etc/ssl/certs/ca-certificates.crt.
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 ai accédé 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 règles).
Faites copier le certificat et le lot dans un fichier .crt et assurez-vous qu'il y a une ligne vide entre les certificats du fichier.
Cela a fonctionné pour moi sur un serveur GitLab après avoir tout essayé sur Internet.