cURL Fehler 60 - TLS-Zertifikate richtig beheben

Ein TLS-Fehler beim Abruf per cURL wirkt auf den ersten Blick wie ein reines Verbindungsproblem, ist in der Praxis aber fast immer ein Hinweis auf Zertifikate, Vertrauenskette oder Hostnamen. In diesem Artikel zeige ich, wie sich der bekannte curl error 60 sauber einordnet, woran er typischerweise liegt und welche Korrektur wirklich hilft, statt nur das Symptom zu überdecken. Der Fokus liegt bewusst auf SSL und Zertifikaten, also genau auf dem Teil, der in Infrastruktur, Deployments und Automatisierung am häufigsten übersehen wird.

Was der Fehler technisch bedeutet

Ich behandle diesen Fehler immer als fehlgeschlagene Vertrauensprüfung, nicht als generelles Netzwerkproblem. cURL prüft bei HTTPS standardmäßig, ob das Serverzertifikat von einer vertrauenswürdigen Zertifizierungsstelle stammt und ob der Name im Zertifikat zum Zielhost passt. Wenn einer dieser Checks scheitert, bricht die Verbindung ab, selbst wenn der Server erreichbar ist und die eigentliche TLS-Verschlüsselung grundsätzlich funktioniert.

Wichtig ist auch die Einordnung im libcurl-Kontext: Fehler 60 steht heute für CURLE_PEER_FAILED_VERIFICATION. Das umfasst nicht nur klassische Zertifikatsprobleme, sondern auch Fingerprint-Prüfungen bei SSH. In der Praxis geht es bei HTTPS aber fast immer um Zertifikate, Zwischenzertifikate, Hostnamen oder den verwendeten CA-Store. Wer nur auf die Zahl schaut, übersieht deshalb leicht den eigentlichen Auslöser.

Ich trenne zusätzlich gern zwischen zwei Ebenen: CURLOPT_SSL_VERIFYPEER prüft, ob das Zertifikat vertrauenswürdig signiert ist, und CURLOPT_SSL_VERIFYHOST prüft, ob der Name zum Zertifikat passt. Genau diese Trennung erklärt, warum manche Verbindungen trotz „gültigem“ Zertifikat fehlschlagen. Als Nächstes schauen wir uns an, welche Bausteine in der Zertifikatskette dabei typischerweise schiefgehen.

Warum Zertifikate, Ketten und Hostnamen oft der Auslöser sind

Ein modernes HTTPS-Zertifikat steht nie allein. Zwischen Serverzertifikat und Root-CA liegt meist mindestens ein Zwischenzertifikat, und genau diese Kette muss vollständig und sauber auflösbar sein. Wenn der Server das Intermediate-Zertifikat nicht mitsendet oder der Client die passende Root-CA nicht kennt, endet die Prüfung mit Fehler 60.

Ebenso häufig ist der Hostname falsch. Das Zertifikat kann technisch korrekt und sogar vertrauenswürdig signiert sein, aber wenn die URL auf api.example.de zeigt und das Zertifikat nur für www.example.de oder eine interne Alias-Name ausgestellt wurde, lehnt cURL die Verbindung ab. Das ist kein kosmetischer Check, sondern verhindert echte Man-in-the-Middle-Szenarien.

Gerade in Unternehmensnetzen kommt noch ein Sonderfall dazu: HTTPS-Inspection oder ein Proxy mit eigener CA. Dann ist das Zertifikat für den Nutzer zwar formal „neu signiert“, aber nur vertrauenswürdig, wenn die Unternehmens-Root-CA sauber in den lokalen Trust-Store eingebunden ist. Damit ist die Diagnose klarer, und ich kann im nächsten Schritt gezielt prüfen, wo die Kette bricht.

So finde ich die Ursache in wenigen Minuten

Mein erster Schritt ist fast immer ein Lauf mit ausführlicher Ausgabe. curl -v https://zielhost.tld zeigt nicht nur den TLS-Handshake, sondern oft auch, welchen CA-Pfad cURL verwendet und an welcher Stelle die Verifikation abbricht. Genau diese Details sind wertvoller als der nackte Fehlercode.

curl -v https://example.tld
curl --trace-ascii /tmp/curl-trace.txt https://example.tld

Wenn -v nicht reicht, liefert --trace-ascii noch mehr Kontext. Das ist besonders nützlich, wenn ein Proxy im Spiel ist, wenn die Verbindung nur in CI scheitert oder wenn die Ausgabe in einem Script kaum aussagekräftig ist. Bei libcurl-Anwendungen würde ich zusätzlich immer einen Error-Buffer aktivieren, weil die menschenlesbare Fehlermeldung oft präziser ist als der Rückgabecode allein.

Danach prüfe ich drei Dinge in genau dieser Reihenfolge:

1. Stimmt die lokale Uhr inklusive Zeitzone und Datum?
2. Welche CA-Datei oder welcher CA-Pfad wird tatsächlich genutzt?
3. Welche konkrete Meldung steht hinter dem Fehler 60, also etwa „expired“, „self signed“ oder „unable to get local issuer“?

Wenn ich den Einsatz schnell eingrenzen will, teste ich außerdem mit einem bewusst anderen CA-Store oder mit einer explizit angegebenen Zertifikatsdatei. Damit sieht man meist sofort, ob das Problem im Client-Trust-Store, auf dem Server oder in der Namensauflösung liegt. Auf dieser Basis lässt sich dann die richtige Lösung auswählen, statt im Blindflug an Optionen zu drehen.

Welche Lösung zu welchem Fall passt

Ich trenne die Korrekturen nach Ursache, weil genau hier die meisten Fehlversuche entstehen. Wer nur eine Sammellösung sucht, landet schnell bei einem unsauberen Workaround. Wer dagegen die Ursache kennt, kann gezielt reparieren und behält die Sicherheit intakt.

Für eigene Zertifikate sind --cacert und bei Verzeichnisstrukturen --capath die üblichen Werkzeuge. Bei OpenSSL-basierten Builds muss ein CA-Verzeichnis vorbereitet sein, damit cURL es korrekt durchsuchen kann. Unter Windows hängt viel davon ab, ob cURL mit Schannel oder mit einer Dateisammlung arbeitet; mit Schannel nutzt cURL den nativen Windows-CA-Store, bei anderen Builds braucht es oft ein Bundle.

Für viele Teams ist auch --ca-native interessant, wenn die jeweilige cURL-Version und das verwendete TLS-Backend das unterstützen. Das ist besonders hilfreich, wenn man den gleichen Client sowohl lokal als auch in gemischten Umgebungen betreibt. Ich würde diese Option aber nur einsetzen, wenn klar ist, dass der native Store tatsächlich die gewünschte Vertrauensquelle ist.

Die eigentliche Frage lautet also nicht „Wie schalte ich die Prüfung ab?“, sondern „Welche Vertrauensquelle ist in meiner Umgebung die richtige?“. Genau dieser Blick verhindert, dass man einen sauberen Fix mit einem unsicheren Umweg verwechselt.

Was sich unter Linux, Windows und in Firmennetzen unterscheidet

In der Theorie ist die Zertifikatsprüfung überall gleich. In der Praxis entscheidet das Betriebssystem oder der TLS-Backend-Stack darüber, woher cURL seine Vertrauensanker bezieht. Das ist der Grund, warum dieselbe URL auf dem Laptop funktioniert, im Container aber scheitert.

Linux und Container

Auf Linux-Systemen läuft die Prüfung meist gegen eine Datei oder ein Verzeichnis mit CA-Zertifikaten. In schlanken Images fehlt das Paket für die CA-Sammlung jedoch erstaunlich oft, und dann scheitert HTTPS nicht am Server, sondern am leeren Trust-Store. In Containern oder CI-Pipelines ist das für mich einer der ersten Verdachtsmomente.

Bei OpenSSL-Setups sollte ein CA-Verzeichnis zudem korrekt aufbereitet sein; sonst findet cURL die Zertifikate nicht zuverlässig. Das klingt banal, ist in der Praxis aber ein häufiger Grund, warum ein Zertifikat „eigentlich vorhanden“ ist und trotzdem nicht akzeptiert wird.

Windows

Unter Windows ist die Build-Variante entscheidend. Mit Schannel verwendet cURL den nativen CA-Store des Betriebssystems, also die Zertifikate, die auch andere Windows-Komponenten kennen. Wird cURL dagegen mit einer anderen TLS-Bibliothek gebaut, kann eine zusätzliche CA-Datei nötig sein, obwohl das System selbst das Zertifikat bereits vertraut.

Genau hier entstehen viele Missverständnisse. Ein Browser kann ein Zertifikat problemlos akzeptieren, während ein bestimmter cURL-Build trotzdem fehlschlägt, weil er eben nicht denselben Trust-Store nutzt. Wer das auseinanderhält, spart sich viel Zeit bei der Fehlersuche.

Lesen Sie auch: Chain Validation Failed - TLS-Fehler beheben & verstehen

Firmennetze und Proxy-Inspection

In Unternehmensumgebungen ersetzt ein Security-Proxy das Serverzertifikat oft transparent durch ein eigenes, intern signiertes Zertifikat. Das ist technisch üblich, aber nur dann sauber, wenn die zugehörige Unternehmens-Root-CA auf dem Client installiert ist. Fehlt sie, sieht cURL nur eine unbekannte Signatur und stoppt mit Fehler 60.

Ich prüfe in solchen Fällen immer, ob die Verbindung direkt oder über einen Proxy läuft und ob die Proxy-Zertifikatskette vollständig ist. Wenn es sich um einen HTTPS-Proxy handelt, sind die Proxy-Optionen von cURL relevant, nicht nur die regulären CA-Parameter für das Zielsystem.

Diese Unterschiede sind der Hauptgrund, warum eine pauschale „funktioniert bei mir“-Diagnose so schnell scheitert. Der nächste Punkt zeigt deshalb, wann ein vermeintlich einfacher Schnellfix eher schadet als hilft.

Warum -k nur die letzte Notbremse ist

-k oder --insecure beendet den Fehler oft sofort, aber genau deshalb ist es gefährlich. Damit wird die Zertifikatsprüfung abgeschaltet, also der Teil, der sicherstellt, dass ich wirklich mit dem richtigen Gegenüber spreche. Verschlüsselung allein reicht nicht, wenn die Identität des Servers nicht mehr verifiziert wird.

Ich setze diese Option höchstens ein, um in einer lokalen, kontrollierten Testsituation einen Verdacht zu bestätigen. Für Skripte, Cronjobs, Deployments oder Produktionssysteme ist sie ungeeignet. Wer den Schalter im Alltag zu früh setzt, maskiert nicht nur den eigentlichen Fehler, sondern öffnet auch die Tür für Man-in-the-Middle-Angriffe.

Die saubereren Alternativen sind fast immer vorhanden: korrektes CA-Bundle, interne Root-CA einbinden, Zertifikat neu ausstellen, Hostname anpassen oder den Proxy-Trust richtig konfigurieren. Das kostet manchmal etwas mehr Zeit als ein Notbehelf, spart aber später genau die Zeit, die man sonst mit versteckten Sicherheitsproblemen verliert.

Womit ich Zertifikatsprobleme dauerhaft klein halte

Wenn ich solche Fehler in Projekten wiederholt vermeiden will, arbeite ich mit ein paar festen Regeln. Erstens halte ich die CA-Stores aktuell, egal ob auf Linux, in Containern oder auf Windows. Zweitens dokumentiere ich, welche Umgebungen den nativen Store nutzen und welche auf eine Datei oder ein Bundle angewiesen sind.

• Serverzertifikate immer mit vollständiger Kette ausliefern.
• Interne Root-CAs zentral verwalten und auf Clients verteilen.
• Ablaufdaten früh monitoren, statt erst bei einem Ausfall zu reagieren.
• In CI und Containern den CA-Stand bewusst prüfen, nicht annehmen.
• Hostnamen im Zertifikat und im Deployment gleich denken, nicht getrennt.
• -k nur in kontrollierten Tests nutzen, nie als Dauerlösung.

Das Entscheidende ist aus meiner Sicht nicht die einzelne Option, sondern die Disziplin in der Zertifikatsverwaltung. Wer Trust-Store, Kette und Hostnamen sauber hält, bekommt Fehler 60 fast vollständig aus dem Alltag heraus. Und genau das ist am Ende die robusteste Lösung für sichere Automatisierung mit cURL.