curl: SSL certificate problem – unable to get local issuer certificate
curl bricht mit Fehler 60 ab? Dein System kennt den Aussteller des Zertifikats nicht. Warum -k die falsche Antwort ist – und was hilft.
Aufwand:
ca. 20 Min.
Voraussetzung:
sudo-Rechte, Terminal
Das Symptom
Der Aufruf, der gestern noch lief, endet abrupt:
„curl: (60) SSL certificate problem: unable to get local issuer
certificate“. Im Browser lädt exakt dieselbe Adresse ohne jede Warnung. Und in
jedem Forum steht derselbe hilfreiche Rat: einfach -k anhängen, dann geht es.
Die „Layer 8“-Wahrheit
Es geht dann auch. Ungefähr so, wie eine Tür schließt, deren Schloss man
ausgebaut hat. Der Schalter schaltet nicht den Fehler ab, sondern die Prüfung –
und damit genau den Teil von TLS, der sicherstellt, dass am anderen Ende der
Leitung wirklich der steht, den du meinst. Die Verschlüsselung bleibt, die
Gewissheit geht. Die Meldung selbst ist dabei völlig sachlich: curl bekommt ein
Zertifikat, kann dessen Aussteller aber in seinem Vorrat nicht finden. Dafür gibt
es drei ehrliche Gründe. Der Zertifikatsspeicher des Systems ist veraltet. Die
Uhr geht falsch, wodurch jedes Zertifikat außerhalb seines Gültigkeitsfensters
liegt. Oder der Server liefert seine Zwischenzertifikate nicht mit – ein Fehler,
den Browser stillschweigend ausbügeln und curl völlig zu Recht meldet. In
Firmennetzen kommt ein vierter dazu: Ein Proxy hört mit, und niemand hat seinem
Zertifikat je erlaubt, dazuzugehören.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Systemzeit prüfen
Zertifikate haben ein Gültigkeitsfenster. Geht die Uhr des Rechners deutlich falsch, gilt jedes Zertifikat als noch nicht oder nicht mehr gültig. Zuerst also Datum und Uhrzeit kontrollieren und die automatische Zeitsynchronisation aktivieren:
timedatectl status
2.
Den Zertifikatsspeicher aktualisieren
Ein veralteter Vorrat an Wurzelzertifikaten ist die häufigste Ursache. Unter Debian und Ubuntu das Paket der Zertifizierungsstellen neu einlesen, unter Fedora und RHEL den entsprechenden Befehl nutzen:
sudo update-ca-certificates
3.
Die Kette der Gegenstelle prüfen
Oft liegt der Fehler nicht bei dir, sondern beim Server: Er liefert sein Zertifikat aus, verschweigt aber das Zwischenzertifikat. Browser gleichen das stillschweigend aus, curl nicht. Mit einer ausführlichen Ausgabe wird die gelieferte Kette sichtbar:
curl -v https://example.com
4.
Firmenzertifikat eintragen
In Firmennetzen bricht ein Proxy die Verbindung bewusst auf und setzt ein eigenes Zertifikat ein. Dann kennt dein System dessen Aussteller nicht. Die richtige Lösung ist, das Wurzelzertifikat der Firma in den Systemspeicher aufzunehmen – nicht, die Prüfung abzuschalten.
5.
Ein Zertifikat gezielt mitgeben
Muss es für einen einzelnen Aufruf ohne Änderung am System gehen, lässt sich der Prüfpfad direkt angeben. Das bleibt sicher, weil geprüft wird – nur eben gegen eine bewusst gewählte Datei:
Der Schalter schaltet die Zertifikatsprüfung komplett ab. Die Verbindung bleibt zwar verschlüsselt, aber niemand prüft mehr, mit wem du sie führst – genau der Schutz, den TLS bieten soll, fällt weg. Damit wird ein Angreifer in der Mitte unsichtbar. Für einen kurzen Test mag das durchgehen, in einem Skript oder gar in der Produktion ist es eine offene Tür.
?Warum funktioniert der Browser, aber curl nicht?
Weil beide unterschiedliche Vorräte an vertrauenswürdigen Ausstellern nutzen. Browser bringen ihren eigenen Zertifikatsspeicher mit oder verwenden den des Betriebssystems, curl greift auf den Zertifikatsspeicher des Systems zu. Fehlt dort ein Zwischenzertifikat oder ist der Speicher veraltet, scheitert curl, während der Browser die Seite anstandslos anzeigt.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Liegen mehrere HTTPS-Namen auf einer IP, entscheidet die SNI-Erweiterung, welches Zertifikat kommt. Fehlt sie, liefert der Server das Standardzertifikat.