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

Die URL ist dein Remote. Mit libcurl 8.22 (und möglicherweise anderen neueren Releases) lautet der Grund „SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)“. Die git-Builds von Debian und Ubuntu verwenden GnuTLS und geben stattdessen „server verification failed: certificate signer not trusted“ aus.

Was der Fehler bedeutet

Der HTTPS-Transport von git verwendet libcurl, und libcurl mit OpenSSL konnte die CA nicht finden, die das letzte vom Git-Server gesendete Zertifikat ausgestellt hat. Entweder lässt der Server sein Zwischenzertifikat weg, oder die Kette endet bei einem Root-Zertifikat (Firmen-CA, Proxy-CA), das nicht in dem Bundle steht, das git verwendet. Unter Windows ist das das klassische Symptom dafür, dass Git for Windows gegen seine eigene mitgelieferte CA-Datei prüft statt gegen den Windows-Zertifikatsspeicher.

Warum der Fehler auftritt

• Git for Windows prüft gegen seine eigene CA-Datei, nicht gegen den Windows-Zertifikatsspeicher

  häufig

  Mit dem standardmäßigen OpenSSL-Backend prüft Git for Windows gegen die mitgelieferte ca-bundle.crt. Root-Zertifikate der Firma und des Proxys, die die IT in den Windows-Zertifikatsspeicher verteilt, stehen nicht in dieser Datei, deshalb scheitern Clones, während Browser funktionieren.

• Ein selbst gehosteter Git-Server mit privater CA

  häufig

  Installationen von GitLab, Gitea, Bitbucket Data Center oder Azure DevOps Server verwenden oft Zertifikate einer internen CA, der CI-Images und neue Rechner nicht vertrauen.

• Der Server lässt sein Zwischenzertifikat weg

  gelegentlich

  Ist der in der Meldung genannte Aussteller eine öffentliche Zwischen-CA, ist der Git-Server oder sein Reverse Proxy nur mit dem Leaf-Zertifikat konfiguriert.

• Eine Überschreibung per http.sslCAInfo oder GIT_SSL_CAINFO ersetzt das Bundle

  gelegentlich

  Eine CA-Datei, die für einen einzelnen internen Host gedacht, aber global konfiguriert ist, ersetzt das Standard-Bundle für jeden Remote, sodass öffentliche Hosts plötzlich scheitern (oder umgekehrt, nachdem die Datei verschoben wurde).

So behebst du den Fehler

1. 1.

   Windows: git auf den Windows-Zertifikatsspeicher umstellen

   Mit http.sslBackend schannel prüft Git for Windows über Windows selbst und akzeptiert jedes Root-Zertifikat, dem Windows vertraut, auch die per Gruppenrichtlinie verteilten. Das ist die saubere Lösung für Firmennetzwerke.

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

   Der CA für einen einzelnen Git-Host vertrauen

   Ein auf eine URL beschränktes http.<url>.sslCAInfo fügt die private CA nur für diesen Host hinzu; GIT_SSL_CAINFO gilt für einen einzelnen Befehl oder 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.

   Root-Zertifikat im System-Bundle installieren

   Unter Linux liest libcurl standardmäßig das System-Bundle; fügst du das Root-Zertifikat dort hinzu, behebt das den Fehler bei git und zugleich bei curl und Paketmanagern.

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

   Nach einer Überschreibung suchen, die das Bundle ersetzt

   --show-origin zeigt dir, welche Konfigurationsdatei einen CA-Pfad setzt. Entferne globale Überschreibungen, die auf einen Host hätten beschränkt sein sollen.

   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.

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

   Verwende -c http.sslVerify=false nur, um die Diagnose zu bestätigen, nie in der globalen Konfiguration: Es legt Zugangsdaten offen und erlaubt jedem auf dem Übertragungsweg, den Code zu verändern, den du abrufst.

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

← Gesamte Signaturfehler-Datenbank durchsuchen