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

Die URL ist dein Remote. Builds auf Basis von OpenSSL 1.1.1 geben „self signed“ ohne Bindestrich aus; libcurl 8.22 gibt „SSL certificate OpenSSL verify result: self-signed certificate in certificate chain (19)“ aus.

Was der Fehler bedeutet

Der Git-Server (oder etwas, das ihm vorgeschaltet ist) hat eine vollständige Kette gesendet, die in einem selbstsignierten Root-Zertifikat endet, und dieses Root-Zertifikat steht nicht im CA-Bundle, das die libcurl von git verwendet. Passiert das bei öffentlichen Hosts wie github.com, gehört das Root-Zertifikat fast immer zu einem Proxy mit TLS-Inspektion in deinem Netzwerk, bei selbst gehosteten Servern zur Firmen-CA.

Warum der Fehler auftritt

• Ein Firmen-Proxy mit TLS-Inspektion

  häufig

  Zscaler, Netskope, Palo Alto, Fortinet und ähnliche Produkte entschlüsseln den Traffic und verschlüsseln ihn mit ihrem eigenen Root-Zertifikat neu. Windows vertraut diesem über eine Gruppenrichtlinie; die mitgelieferte CA-Datei von Git for Windows, WSL, Docker und CI-Images tun das nicht.

• Der selbst gehostete Git-Server sendet sein privates Root-Zertifikat

  häufig

  Ein internes GitLab oder Gitea, das Leaf-Zertifikat, Zwischenzertifikat und das Root-Zertifikat der Firma ausliefert, erfordert trotzdem, dass das Root-Zertifikat auf jedem Client installiert ist.

• HTTPS-Scan durch Antivirensoftware

  gelegentlich

  Endpoint-Security-Produkte mit Funktionen wie „HTTPS-Scan“ oder „Web-Schutz“ installieren ihr eigenes Root-Zertifikat auf dem Rechner; es erscheint in dieser Kette genauso wie das eines Proxys.

So behebst du den Fehler

1. 1.

   Root-Zertifikat identifizieren

   Gib die Kette für einen öffentlichen Host aus. Trägt das oberste Zertifikat den Namen deiner Firma oder eines Security-Anbieters, wird die Verbindung inspiziert, und genau diesem Root-Zertifikat muss git vertrauen. Erkennst du es überhaupt nicht, vertraue ihm nicht: Geh der Sache zuerst nach.

   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: Windows-Zertifikatsspeicher verwenden

   Git for Windows mit http.sslBackend schannel vertraut allem, dem Windows vertraut – auf verwalteten Rechnern gehört das Root-Zertifikat des Proxys bereits dazu.

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

3. 3.

   Root-Zertifikat zum Bundle hinzufügen, das git verwendet

   http.sslCAInfo ersetzt das Standard-Bundle; erstelle deshalb eine Datei, die die öffentlichen Root-Zertifikate und zusätzlich das Root-Zertifikat des Proxys oder der Firma enthält.

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

   Root-Zertifikat unter Linux systemweit installieren

   update-ca-certificates fügt das Root-Zertifikat auf einmal für git, curl, wget, pip und die meisten anderen Tools hinzu.

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

5. 5.

   Vorübergehende Diagnose: Prüfung für einen einzelnen Befehl überspringen

   Nur, um die Diagnose zu bestätigen. Schaltest du die Prüfung für die eigentliche Arbeit ab, lieferst du deine Git-Zugangsdaten und deinen Quellcode jedem aus, der die Verbindung terminiert.

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

← Gesamte Signaturfehler-Datenbank durchsuchen