verify error:num=20:unable to get local issuer certificate

s_client gibt während des Handshakes „verify error:num=20:…“ und in seiner Zusammenfassung „Verify return code: 20 (…)“ aus; openssl verify gibt „error 20 at <depth> depth lookup: …“ aus. Standardmäßig macht s_client nach Fehlern bei der Prüfung weiter; füge -verify_return_error hinzu, damit es abbricht.

OpenSSL CLI (openssl s_client / openssl verify) — X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY

Was der Fehler bedeutet

OpenSSL-Fehler 20 (X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY): Beim Aufbau der Kette ist OpenSSL auf ein Zertifikat gestoßen, dessen Aussteller sich weder unter den vom Server gesendeten Zertifikaten noch im Trust Store finden ließ. Die direkt davor ausgegebene depth-Zeile nennt das Zertifikat, dessen Aussteller fehlt. Derselbe Code steckt hinter (60) bei curl, CERTIFICATE_VERIFY_FAILED bei Python und UNABLE_TO_GET_ISSUER_CERT_LOCALLY bei Node.js.

Warum der Fehler auftritt

• Die Kette endet bei einem Root-Zertifikat, das nicht im Trust Store steht

  häufig

  Ein privates oder firmeneigenes Root-Zertifikat (oder ein Proxy mit TLS-Inspektion, der nur sein Zwischenzertifikat sendet). Die depth-Zeile mit der höchsten Zahl nennt ein Zwischenzertifikat, dessen Aussteller dir fehlt.

• Der Server sendet sein Zwischenzertifikat nicht

  häufig

  Nur das Zertifikat auf depth=0 erscheint, und sein Aussteller ist eine Zwischen-CA. OpenSSL lädt fehlende Zwischenzertifikate nie herunter, deshalb muss der Server sie senden.

• Für den Test wurde kein Trust Store verwendet

  gelegentlich

  openssl verify mit einem einzelnen Zertifikat oder s_client in einem Image ohne ca-certificates hat keine Root-Zertifikate, mit denen sich die Kette vervollständigen lässt, selbst bei öffentlichen Websites.

So behebst du den Fehler

1. 1.

   depth-Zeilen lesen

   Tiefe 0 ist das Zertifikat des Servers, höhere Zahlen sind die Zwischenzertifikate, die er gesendet hat. Die letzte depth-Zeile vor dem Fehler gehört zu dem Zertifikat, dessen Aussteller fehlt.

   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>&1 | grep -E '^depth|verify'
   # depth=1 CN=Example Corp Issuing CA       <- the highest certificate received
   # verify error:num=20:...                   <- its issuer is not in the trust store

2. 2.

   Mit dem erwarteten Root-Zertifikat testen

   -CAfile mit dem richtigen Root-Zertifikat (und -verify_return_error, damit Fehler zum Abbruch führen) zeigt, ob dieses Root-Zertifikat die Kette vervollständigt; „Verify return code: 0 (ok)“ bedeutet, dass es das tut.

   # Verify against a specific root (exit code and "Verify return code: 0 (ok)" confirm it)
   echo | openssl s_client -connect api.example.com:443 -servername api.example.com \
     -CAfile corp-root-ca.pem -verify_return_error 2>&1 | grep 'Verify return code'

3. 3.

   Zertifikatsdateien offline prüfen

   Übergib openssl verify das Root-Zertifikat als -CAfile und die Zwischenzertifikate als -untrusted; ein Leaf-Zertifikat allein lässt sich nicht prüfen.

   # Offline: root as trust anchor, intermediate(s) as untrusted helpers
   openssl verify -CAfile corp-root-ca.pem -untrusted intermediate.pem server.pem

4. 4.

   Root-Zertifikat im Trust Store des Systems installieren

   Endet die Kette legitimerweise bei einem firmeneigenen Root-Zertifikat, füge es dem Trust Store der Distribution hinzu; Tools auf OpenSSL-Basis vertrauen ihm dann auf diesem Rechner.

   sudo cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt
   sudo update-ca-certificates     # openssl reads /etc/ssl/certs by default on Debian/Ubuntu

← Gesamte Signaturfehler-Datenbank durchsuchen