TLS-Verifikationsfehler in verschiedenen Tools: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed in chain

Worum es geht

Mehrere TLS-Clients beschreiben denselben zugrunde liegenden Fehler, nämlich dass sich keine Kette vom Zertifikat des Servers zu einem bereits als vertrauenswürdig geführten Zertifikat aufbauen liess, jeweils in ihrer eigenen Terminologie. Go (crypto/x509) meldet x509: certificate signed by unknown authority (seit Go 1.20 mit dem Präfix tls: failed to verify certificate:). Das Python-Modul ssl, das OpenSSL kapselt, löst [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate aus; dieser Fehler ist in der Referenz des Moduls selbst dokumentiert. curl meldet curl: (60) SSL certificate problem:, gefolgt von unable to get local issuer certificate oder self-signed certificate in certificate chain, je nachdem, an welcher Stelle die Kette genau abbricht, wie die curl-Dokumentation zu SSL-Zertifikatsproblemen beschreibt; OpenSSL 1.1.1 schreibt es als self signed. Node.js und openssl s_client melden eine Kette, die nur aus dem Leaf-Zertifikat eines unbekannten Ausstellers besteht, als unable to verify the first certificate.

Warum es wichtig ist

Die Formulierung gibt Hinweise auf die Ursache, identifiziert sie aber nicht zuverlässig, und Raten kostet Zeit: Ein fehlendes Intermediate-Zertifikat ist eine Fehlkonfiguration des Servers; ein selbstsigniertes Root-Zertifikat am Ende der Kette ist entweder eine legitime private CA oder, in seltenen Fällen, aktives Abfangen des Datenverkehrs. Behoben wird keines von beiden, indem die Verifikation abgeschaltet wird.

So wird es angewendet

• Zuerst diagnostizieren: openssl s_client -connect host:443 -servername host </dev/null, dokumentiert in der s_client-Manpage von OpenSSL, gibt die Zertifikatskette aus, die der Server gesendet hat (mit -showcerts zusätzlich die vollständigen PEM-Blöcke), sowie am Ende eine Zeile Verify return code:. Endet die Kette beim Leaf-Zertifikat ohne Intermediate, sendet der Server sein Intermediate-Bundle nicht mit. Sind beim letzten Zertifikat die Felder Issuer und Subject identisch, endet die Kette in einem selbstsignierten Zertifikat. Das ist entweder die eigene private bzw. interne CA, der der Client noch nicht vertraut, oder, falls überhaupt kein selbstsigniertes Root-Zertifikat zu erwarten war, ein Hinweis darauf, dass der Datenverkehr abgefangen werden könnte.
• Korrekturen, von der am wenigsten bis zur am stärksten eingreifenden:
  1. Fehlendes Intermediate bei einer ansonsten öffentlichen CA: das Zertifikatsbundle des Servers so korrigieren, dass es die vollständige Kette enthält; das ist kein Problem auf Client-Seite.
  2. Private oder interne CA (verbreitet hinter Firmen-Proxys und auf manchen CI-Runnern): diese CA in den Trust Store installieren, den das betreffende fehlschlagende Tool tatsächlich verwendet, denn der cacerts-Store von Java, das certifi-Bundle von Python, der eigene Store von Node und der System-Store von curl/OpenSSL sind jeweils voneinander getrennt.
  3. Hat sich die Kette unerwartet geändert und besteht der Verdacht auf Abfangen, ist das als Sicherheitsvorfall zu behandeln: das Zertifikat über einen separaten Kanal prüfen, bevor es weitergeht, nicht durch Abschalten der Prüfung.
• Unsicher: curl -k/--insecure, verify=False in Python, NODE_TLS_REJECT_UNAUTHORIZED=0 oder git -c http.sslVerify=false. Jede dieser Optionen schaltet genau die Prüfung ab, die einen echten Man-in-the-Middle-Angriff erkennen würde, und keine davon sollte zur dauerhaften Lösung werden.

Stolpersteine

• Der Trust Store wird für ein Tool (das Betriebssystem) korrigiert, während ein anderes Tool (eine JVM, ein Python-venv) ein eigenes, separates Bundle führt und weiterhin fehlschlägt.
• Ein vorübergehendes Abfangen (ein TLS-inspizierender Firmen-Proxy) wird als Erlaubnis verstanden, die Verifikation überall abzuschalten, statt nur der spezifischen CA dieses Proxys zu vertrauen.