ERROR: cannot verify api.example.com's certificate, issued by 'CN=Example Private CA':

Hostname und Distinguished Name des Ausstellers ändern sich mit jeder Website. GnuTLS-Builds von wget (Debian) melden denselben Fehler als „ERROR: The certificate of '<host>' is not trusted.“

Was der Fehler bedeutet

Das OpenSSL-Backend von wget konnte das Serverzertifikat nicht prüfen; dessen Aussteller steht in der Meldung nach „issued by“. Die eingerückte Zeile, die wget danach ausgibt, nennt den Grund von OpenSSL. „Unable to locally verify the issuer's authority“ bedeutet, dass der Aussteller nicht im lokalen CA-Bundle steht und der Server kein Zertifikat gesendet hat, das zu einem Zertifikat aus diesem Bundle führt. wget bricht mit Exit-Status 5 ab.

Warum der Fehler auftritt

• Der Aussteller ist eine private oder firmeneigene CA

  häufig

  Ist der genannte Aussteller die CA deiner Organisation oder die CA eines Tools wie Kubernetes oder Vault, steht ihr Root-Zertifikat nicht im öffentlichen Bundle auf diesem Rechner.

• Der Server lässt sein Zwischenzertifikat weg

  häufig

  Ist der Aussteller eine öffentliche Zwischen-CA („R13“, „GTS CA 1C3“, „Sectigo RSA Domain Validation…“), hat der Server ihr Zertifikat nicht mitgesendet; ohne dieses kann OpenSSL das Leaf-Zertifikat nicht mit einem vertrauenswürdigen Root-Zertifikat verbinden.

• Ein Proxy mit TLS-Inspektion hat das Zertifikat ausgestellt

  gelegentlich

  Gehört der Name des Ausstellers bei einer öffentlichen Website zu einem Security-Anbieter oder zu deiner Firma, signiert ein Proxy den Traffic neu. Sein Root-Zertifikat muss auf dem Rechner installiert sein, auf dem wget läuft.

• Das CA-Bundle ist veraltet

  selten

  Systemen, die ca-certificates seit Jahren nicht aktualisiert haben, können Root-Zertifikate fehlen, zu denen die Ketten neuerer öffentlicher Zertifikate führen.

So behebst du den Fehler

1. 1.

   Eingerückte Zeile mit dem Grund lesen

   Die Zeile unter der ERROR-Zeile zeigt, welche der OpenSSL-Prüfungen fehlgeschlagen ist – und damit, ob du das Vertrauen, die Kette des Servers oder die Datumsangaben korrigieren musst.

   ERROR: cannot verify api.example.com's certificate, issued by 'CN=Example Private CA':
     Unable to locally verify the issuer's authority.     <- issuer unknown: CA or chain problem
     Self-signed certificate encountered.                 <- server certificate is self-signed
     Issued certificate has expired.                      <- date problem

2. 2.

   wget auf die CA verweisen

   Übergib das Root-Zertifikat (oder ein Bundle) mit --ca-certificate oder setze ca_certificate in ~/.wgetrc oder /etc/wgetrc.

   wget --ca-certificate=/opt/certs/corp-root-ca.pem https://api.example.com/
   echo 'ca_certificate = /opt/certs/corp-root-ca.pem' >> ~/.wgetrc

3. 3.

   Root-Zertifikat im System-Bundle installieren

   wget auf OpenSSL-Basis liest das Bundle der Distribution; trägst du das Root-Zertifikat dort ein, behebt das den Fehler für wget, curl und die meisten anderen Tools auf dem Rechner auf einmal.

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

4. 4.

   Eigener Server: vollständige Kette ausliefern

   Ist der Aussteller eine öffentliche Zwischen-CA, konfiguriere den Server mit dem Leaf-Zertifikat, gefolgt von den Zwischenzertifikaten.

   # Server side: serve leaf + intermediates
   cat api.example.com.crt intermediate.crt > fullchain.pem

5. 5.

   Vorübergehende Diagnose: Prüfung einmalig überspringen

   --no-check-certificate zeigt, ob der Download ansonsten funktionieren würde. Die Option akzeptiert jedes Zertifikat, auch das eines Angreifers; verwende sie deshalb für nichts, was du ausführst oder worauf du dich verlässt.

   # Diagnostic only
   wget --no-check-certificate -O /dev/null https://api.example.com/

← Gesamte Signaturfehler-Datenbank durchsuchen