curl-Fehler 77: Zertifikatprüfungspfade bei einer VPN-Installation

Sie fügen den Ein-Zeiler des Installers aus einem Tutorial ein, drücken Enter und erhalten curl: (77). Die Meldung erwähnt Zertifikatprüfungspfade, also liegt der Reflex nahe, das Zertifikat des VPN-Anbieters sei kaputt, und nach einem Flag zu greifen, das die Prüfung überspringt. Diese Lesart ist falsch, und wer danach handelt, macht aus einem lokalen Dateiproblem eine Sicherheitsentscheidung. Gehen wir es von Anfang an durch.

Schritt 1: Lesen Sie, was die Nummer bedeutet

Fehler 77 betrifft die lokale CA-Eingabe: curl konnte das Zertifikatmaterial, dem es vertrauen sollte, nicht lesen oder laden. Fehler 60 ist der zur Gegenseite, bei dem die Kette des Servers nicht validiert. In Tutorials stehen sie nebeneinander und bedeuten das Gegenteil.

Wenn Ihre Ausgabe 77 sagt, war der Server nie das Problem. Der Client konnte die Datei nicht öffnen, die er zur Prüfung verwenden wollte, und das ist ein Pfad-, Rechte- oder Paketierungsproblem auf Ihrem Rechner.

Schritt 2: Lesen Sie den Befehl, den Sie kopiert haben

Kopierte Befehle verstecken Zeichen. Kleingeschriebenes -l ist --list-only, das sich auf das Auflisten von Protokollen bezieht. Großgeschriebenes -L ist --location, das einer HTTP-Weiterleitung folgt. Das sind keine alternativen Schreibweisen, und ein Tutorial, das das eine schreibt, während es das andere beschreibt, schickt Leute auf einen Weiterleitungspfad, der nie beabsichtigt war.

Einer Weiterleitung zu folgen repariert keinen Trust-Store-Pfad und belegt nicht, dass der endgültige Host der Herausgeber ist, den Sie meinten. Wenn der Befehl aus einem Forenbeitrag stammt, tippen Sie ihn aus den eigenen Anweisungen des Projekts neu ab, statt der Einfügung zu vertrauen.

Schritt 3: Finden Sie heraus, welche CA-Eingabe dieser Build verwendet

Beginnen Sie mit der Identifikation der Binärdatei, denn die Antwort hängt davon ab, wie sie kompiliert wurde:

curl --version

Notieren Sie Version und TLS-Backend. Ein Build mit nativem Trust Store liest den Systemstore über die TLS-Bibliothek, während ein auf ein Bundle gerichteter Build eine Datei liest. Ein explizites --cacert, eine CURL_CA_BUNDLE-Einstellung oder ein Shell-Wrapper können beides überschreiben, sodass eine Paketinstallation die Datei, die tatsächlich fehlschlägt, möglicherweise gar nicht berührt.

Prüfen Sie bei einem dateibasierten Store drei Dinge der Reihe nach: Existiert der Pfad, kann das aufrufende Konto ihn lesen, und enthält er das erwartete CA-Material. Ein Bundle mit falschen Berechtigungen schlägt genauso fehl wie ein fehlendes, und beide schlagen fehl, bevor irgendein Netzwerkgespräch über den Server stattfindet.

Schritt 4: Reparieren Sie die Eingabe, nicht die Prüfung

Stellen Sie die unterstützte Vertrauenskonfiguration über denjenigen wieder her, dem sie gehört: das Distributionspaket, Ihre Konfigurationsverwaltung oder die dokumentierte Umgebungsvariable. Das Ziel ist eine lesbare, korrekte CA-Eingabe für diese Binärdatei.

Wechseln Sie die URL nicht auf HTTP, fügen Sie kein --insecure hinzu und vertrauen Sie keinem Zertifikat, das aus einem unerklärten Download kopiert wurde. Jede dieser Änderungen ändert, was Sie zu akzeptieren bereit sind, statt zu reparieren, was curl nicht lesen konnte, und die Änderung überlebt den Vorfall meist.

Die Referenz für die Nummern ist der curl-Fehlerkatalog, und er ist kurz genug, um ihn einmal richtig zu lesen.

Schritt 5: Herunterladen, ansehen, dann ausführen

Laden Sie den Installer in eine Datei herunter, statt ihn im selben Befehl in eine Shell zu pipen. Diese eine Änderung trennt eine Übertragung, die Sie prüfen können, von Code, der mit Ihren Rechten läuft.

curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.sh

Prüfen Sie, ob die Antwort das erwartete Skript ist und nicht eine HTML-Fehlerseite, ein Weiterleitungshinweis oder eine leere Datei. Wenn der Herausgeber eine Prüfsumme oder Signatur bereitstellt, verifizieren Sie sie über seinen dokumentierten Release-Prozess und nicht über einen Wert, der im selben Forenthread zitiert wird.

Denken Sie daran, was HTTPS getan hat und was nicht. Es hat den Transport zu dem Host authentifiziert, den Sie kontaktiert haben; es hat den Inhalt des Skripts nicht geprüft und sagt Ihnen nicht, ob der Herausgeber vertrauenswürdig ist.

Schritt 6: Halten Sie die Installationsschritte getrennt

Die Datei herunterzuladen, den Client zu installieren, den Tunnel zu konfigurieren und Routen zu validieren sind vier Vorgänge mit vier verschiedenen Fehlerarten. Sie nacheinander zu erledigen bedeutet, dass ein Fehler später in der Reihenfolge eine offensichtliche Ursache hat statt vier Kandidaten.

Wenn die Installation gelingt und der Tunnel hochkommt, prüfen Sie die Routen und ein echtes Ziel, bevor Sie das Ticket schließen. Der curl-Fehler ist behoben, wenn ein einfaches curl -I https://example.invalid wieder funktioniert, nicht wenn der Installer aufhört zu klagen.