curl: (77) error setting certificate file: /etc/pki/tls/certs/ca-bundle.crt

curl ab 7.81 gibt „error setting certificate file: <path>“ aus (oder „error setting certificate path“ bei einem CA-Verzeichnis); curl 7.74 und älter gab „error setting certificate verify locations:“ aus, gefolgt von den Werten für CAfile und CApath. Der Pfad ist der, den deine Konfiguration nennt.

curl (OpenSSL backend) — CURLE_SSL_CACERT_BADFILE

Was der Fehler bedeutet

curl konnte das CA-Bundle, das es verwenden soll, nicht laden und verweigert deshalb jede HTTPS-Anfrage. An den Server wurde nichts gesendet: Der Fehler tritt vor dem Verbindungsaufbau auf, während curl die nach dem Doppelpunkt genannte Datei liest. Der Pfad stammt aus --cacert, CURL_CA_BUNDLE, SSL_CERT_FILE, einer .curlrc-Datei oder dem in curl einkompilierten Standardwert.

Warum der Fehler auftritt

• Ein Pfad aus einer anderen Distribution

  häufig

  Skripte, Dockerfiles und CI-Vorlagen, die für RHEL geschrieben wurden, exportieren CURL_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt; dieselbe Zeile nennt unter Debian, Ubuntu oder Alpine eine Datei, die es dort nicht gibt (und umgekehrt mit /etc/ssl/certs/ca-certificates.crt).

• Im Image ist kein CA-Bundle installiert

  häufig

  Minimale Images lassen das Paket ca-certificates oft weg, sodass der in curl einkompilierte Standardpfad ins Leere zeigt.

• Die Datei existiert, lässt sich aber nicht lesen

  gelegentlich

  Ein Bundle, das nur root lesen darf, ein nach einem Upgrade defekter Symlink oder eine leere Datei, die ein fehlgeschlagener Kopiervorgang abgeschnitten hat, erzeugen alle dieselbe Meldung.

• Ein relativer Pfad, der von einem anderen Verzeichnis aus aufgelöst wird

  gelegentlich

  --cacert certs/ca.pem funktioniert im Projektordner und scheitert, wenn ein Cronjob, eine systemd-Unit oder ein CI-Schritt curl aus einem anderen Arbeitsverzeichnis startet.

So behebst du den Fehler

1. 1.

   Herausfinden, woher der Pfad stammt

   Suche in der Umgebung und in ~/.curlrc nach einer CA-Einstellung und prüfe mit curl -V die TLS-Bibliothek: OpenSSL-Builds beachten CURL_CA_BUNDLE und SSL_CERT_FILE, Schannel- und Secure-Transport-Builds verwenden den Speicher des Systems, sofern nichts anderes angegeben ist.

   env | grep -E 'CURL_CA_BUNDLE|SSL_CERT_FILE|SSL_CERT_DIR'
   grep -sE 'cacert|capath' ~/.curlrc
   curl -V | head -1            # which TLS library this curl uses

2. 2.

   Bundle-Pfad dieser Distribution verwenden oder gar keinen

   Meist ist es die richtige Lösung, die Überschreibung zu entfernen: curl verwendet dann den Bundle-Pfad, mit dem sein Paket gebaut wurde. Brauchst du ein eigenes Bundle, verweise auf eine Datei, die auf diesem System existiert.

   # Debian, Ubuntu, Alpine:        /etc/ssl/certs/ca-certificates.crt
   # RHEL, Fedora, Amazon Linux:    /etc/pki/tls/certs/ca-bundle.crt
   # openSUSE:                      /etc/ssl/ca-bundle.pem
   unset CURL_CA_BUNDLE        # let curl use the bundle it was built with
   ls -l /etc/ssl/certs/ca-certificates.crt

3. 3.

   Paket mit dem CA-Bundle installieren

   Füge in Slim-Images und von Distroless abgeleiteten Images ca-certificates beim Build hinzu, damit der Standardpfad existiert.

   apt-get install -y ca-certificates     # Debian/Ubuntu
   apk add --no-cache ca-certificates     # Alpine
   dnf install -y ca-certificates         # RHEL/Fedora

4. 4.

   Datei lesbar machen und einen absoluten Pfad verwenden

   Das Konto, unter dem curl läuft, braucht Lesezugriff auf das Bundle. Absolute Pfade funktionieren weiter, wenn sich das Arbeitsverzeichnis ändert.

   ls -l /opt/certs/bundle.pem
   sudo chmod 0644 /opt/certs/bundle.pem
   curl --cacert "$(realpath /opt/certs/bundle.pem)" https://api.example.com/

← Gesamte Signaturfehler-Datenbank durchsuchen