fatal: unable to access 'https://git.example.com/team/app.git/': SSL certificate problem: unable to get local issuer certificate

L’URL est celle de votre dépôt distant. Avec libcurl 8.22 (et peut-être d’autres versions récentes), la raison s’affiche sous la forme « SSL certificate OpenSSL verify result: unable to get local issuer certificate (20) ». Les builds de git de Debian et d’Ubuntu utilisent GnuTLS et affichent à la place « server verification failed: certificate signer not trusted ».

Ce que cela signifie

Le transport HTTPS de git utilise libcurl, et libcurl avec OpenSSL n’a pas trouvé l’AC qui a émis le dernier certificat envoyé par le serveur Git. Soit le serveur omet son certificat intermédiaire, soit la chaîne se termine par une racine (AC d’entreprise, AC de proxy) absente du fichier d’AC qu’utilise git. Sous Windows, c’est le symptôme classique de Git for Windows qui vérifie avec son propre fichier d’AC fourni au lieu du magasin de certificats Windows.

Pourquoi cela se produit

• Git for Windows consulte son propre fichier d’AC, et non le magasin Windows

  fréquente

  Avec le backend OpenSSL par défaut, Git for Windows vérifie les certificats à l’aide du ca-bundle.crt qu’il fournit. Les racines d’entreprise et de proxy que l’équipe informatique déploie dans le magasin de certificats Windows ne figurent pas dans ce fichier : les clones échouent donc alors que les navigateurs fonctionnent.

• Un serveur Git auto-hébergé avec une AC privée

  fréquente

  Les installations de GitLab, Gitea, Bitbucket Data Center ou Azure DevOps Server utilisent souvent des certificats d’une AC interne que les images de CI et les nouvelles machines n’approuvent pas.

• Le serveur omet son certificat intermédiaire

  occasionnelle

  Si l’émetteur cité est une AC intermédiaire publique, le serveur Git ou son proxy inverse est configuré avec le seul certificat feuille.

• Une surcharge http.sslCAInfo ou GIT_SSL_CAINFO remplace le fichier d’AC

  occasionnelle

  Un fichier d’AC prévu pour un seul hôte interne, mais configuré globalement, remplace le fichier d’AC par défaut pour tous les dépôts distants : les hôtes publics se mettent alors à échouer (ou l’inverse, après le déplacement du fichier).

Comment corriger l’erreur

1. 1.

   Windows : faire passer git au magasin de certificats Windows

   Avec http.sslBackend schannel, Git for Windows vérifie les certificats via Windows lui-même et accepte toutes les racines que Windows approuve, y compris celles déployées par stratégie de groupe. C’est la correction propre pour les réseaux d’entreprise.

   # Git for Windows: verify with the Windows certificate store, where IT deploys company roots
   git config --global http.sslBackend schannel
   git config --global --get http.sslBackend

2. 2.

   Faire confiance à l’AC pour un seul hôte Git

   Un http.<url>.sslCAInfo limité à une URL ajoute l’AC privée pour cet hôte uniquement ; GIT_SSL_CAINFO s’applique à une seule commande ou à un seul job.

   git config --global http."https://git.example.com/".sslCAInfo /etc/ssl/private-ca/corp-root-ca.pem
   # one command or CI job only
   GIT_SSL_CAINFO=/etc/ssl/private-ca/corp-root-ca.pem git clone https://git.example.com/team/app.git

3. 3.

   Installer la racine dans le fichier d’AC du système

   Sous Linux, libcurl lit par défaut le fichier d’AC du système : y ajouter la racine corrige donc git, ainsi que curl et les gestionnaires de paquets.

   # Alpine / Debian / Ubuntu
   cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt && update-ca-certificates
   # RHEL / Fedora
   cp corp-root-ca.pem /etc/pki/ca-trust/source/anchors/ && update-ca-trust

4. 4.

   Chercher une surcharge qui remplace le fichier d’AC

   --show-origin indique quel fichier de configuration définit un chemin d’AC. Supprimez les surcharges globales qui auraient dû être limitées à un hôte.

   git config --show-origin --get-all http.sslCAInfo
   git config --show-origin --get-regexp 'http\..*\.sslcainfo'
   env | grep -E 'GIT_SSL_CAINFO|CURL_CA_BUNDLE|SSL_CERT_FILE'

5. 5.

   Diagnostic temporaire : désactiver la vérification pour une seule commande

   N’utilisez -c http.sslVerify=false que pour confirmer le diagnostic, jamais dans la configuration globale : cela expose les identifiants et permet à quiconque se trouve sur le chemin de modifier le code que vous récupérez.

   # Diagnostic only, for one command
   git -c http.sslVerify=false ls-remote https://git.example.com/team/app.git

← Parcourir toute la base de données des erreurs de signature