fatal: unable to access 'https://git.example.com/team/app.git/': SSL certificate problem: self-signed certificate in certificate chain

L’URL est celle de votre dépôt distant. Les builds reposant sur OpenSSL 1.1.1 affichent « self signed » sans trait d’union ; libcurl 8.22 affiche « SSL certificate OpenSSL verify result: self-signed certificate in certificate chain (19) ».

Ce que cela signifie

Le serveur Git (ou un équipement placé devant lui) a envoyé une chaîne complète qui se termine par une racine auto-signée, et cette racine ne figure pas dans le fichier d’AC qu’utilise la libcurl de git. Lorsque cela se produit avec des hôtes publics comme github.com, la racine appartient presque toujours à un proxy d’inspection TLS de votre réseau ; avec des serveurs auto-hébergés, à l’AC de l’entreprise.

Pourquoi cela se produit

• Un proxy d’inspection TLS d’entreprise

  fréquente

  Zscaler, Netskope, Palo Alto, Fortinet et les produits similaires déchiffrent puis rechiffrent le trafic avec leur propre racine. Windows approuve cette racine via une stratégie de groupe ; ce n’est pas le cas du fichier d’AC fourni avec Git for Windows, de WSL, ni des images Docker et de CI.

• Le serveur Git auto-hébergé envoie sa racine privée

  fréquente

  Un GitLab ou un Gitea interne qui sert le certificat feuille, le certificat intermédiaire et la racine de l’entreprise exige quand même que cette racine soit installée sur chaque client.

• Analyse HTTPS par l’antivirus

  occasionnelle

  Les solutions de sécurité des endpoints dotées de fonctions « HTTPS scanning » ou « web shield » installent leur propre racine sur la machine ; elle apparaît dans cette chaîne de la même façon que celle d’un proxy.

Comment corriger l’erreur

1. 1.

   Identifier la racine

   Affichez la chaîne d’un hôte public. Si le certificat le plus haut de la chaîne porte le nom de votre entreprise ou d’un éditeur de sécurité, la connexion est inspectée, et c’est à cette racine que git doit faire confiance. Si vous ne la reconnaissez pas du tout, ne lui faites pas confiance : enquêtez d’abord.

   openssl s_client -connect github.com:443 -servername github.com -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'
   # A root named after your company or a security vendor = interception proxy

2. 2.

   Windows : utiliser le magasin de certificats Windows

   Avec http.sslBackend schannel, Git for Windows fait confiance à tout ce que Windows approuve, ce qui, sur les machines gérées, inclut déjà la racine du proxy.

   # Git for Windows: use the Windows certificate store, which already trusts the proxy root
   git config --global http.sslBackend schannel

3. 3.

   Ajouter la racine au fichier d’AC qu’utilise git

   http.sslCAInfo remplace le fichier d’AC par défaut : constituez donc un fichier qui contient les racines publiques, plus la racine du proxy ou de l’entreprise.

   # Linux/macOS/WSL: append the proxy root to a bundle that keeps the public roots
   cat /etc/ssl/certs/ca-certificates.crt corp-proxy-root.pem > ~/.config/git/ca-bundle.pem
   git config --global http.sslCAInfo ~/.config/git/ca-bundle.pem

4. 4.

   Installer la racine pour tout le système sous Linux

   update-ca-certificates ajoute la racine pour git, curl, wget, pip et la plupart des autres outils en une seule fois.

   sudo cp corp-proxy-root.pem /usr/local/share/ca-certificates/corp-proxy-root.crt
   sudo update-ca-certificates

5. 5.

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

   Uniquement pour confirmer le diagnostic. Désactiver la vérification pour le travail réel livre vos identifiants Git et votre code source à quiconque se trouve à l’autre bout de la connexion.

   # 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