curl-fejl 77: certifikatverifikationsplaceringer ved en VPN-installation

Du indsætter installationskommandoen på én linje fra en vejledning, trykker Enter og får curl: (77). Beskeden nævner certifikatverifikationsplaceringer, så instinktet er at antage, at VPN-udbyderens certifikat er i stykker, og gribe efter et flag, der springer verifikationen over. Den læsning er forkert, og at handle på den gør et lokalt filproblem til en sikkerhedsbeslutning. Lad os gå det igennem fra begyndelsen.

Trin 1: læs, hvad tallet betyder

Fejl 77 handler om det lokale CA-input: curl kunne ikke læse eller indlæse det certifikatmateriale, den blev bedt om at stole på. Fejl 60 er den om modparten, hvor serverens kæde ikke validerer. De optræder side om side i vejledninger og betyder det modsatte.

Hvis din udskrift siger 77, var serveren aldrig problemet. Klienten kunne ikke åbne den fil, den ville bruge til kontrollen, og det er et sti-, tilladelses- eller pakningsproblem på din maskine.

Trin 2: læs den kommando, du kopierede

Kopierede kommandoer skjuler tegn. Lille -l er --list-only, som gælder visning af protokoller. Stort -L er --location, som følger en HTTP-omdirigering. De er ikke alternative stavemåder, og en vejledning, der skriver det ene, mens den beskriver det andet, sender folk ned ad en omdirigeringsvej, der aldrig var hensigten.

At følge en omdirigering reparerer ikke en tillidslagersti, og det beviser ikke, at den endelige vært er den udgiver, du mente. Hvis kommandoen kom fra et forumindlæg, skal du skrive den om fra projektets egne instruktioner i stedet for at stole på indsættelsen.

Trin 3: find ud af, hvilket CA-input det build bruger

Begynd med at identificere binæren, fordi svaret afhænger af, hvordan den blev kompileret:

curl --version

Noter versionen og TLS-backenden. Et build med et natives tillidslager læser systemlageret via TLS-biblioteket, mens et build rettet mod en bundle læser en fil. Et eksplicit --cacert, en CURL_CA_BUNDLE-indstilling eller en shell-wrapper kan tilsidesætte begge, så en pakkeinstallation rører måske ikke den fil, der faktisk fejler.

For et filbaseret lager skal du kontrollere tre ting i rækkefølge: findes stien, kan den kaldende konto læse den, og indeholder den det CA-materiale, du forventer. En bundle med forkerte tilladelser fejler på samme måde som en manglende, og begge fejler, før der sker nogen netværkssamtale om serveren.

Trin 4: reparer inputtet, ikke verifikationen

Gendan den understøttede tillidskonfiguration gennem den, der ejer den: distributionspakken, din konfigurationsstyring eller den dokumenterede miljøvariabel. Målet er et læsbart og korrekt CA-input til den binære.

Skift ikke URL’en til HTTP, tilføj ikke --insecure, og stol ikke på et certifikat kopieret fra en uforklaret download. Hver af disse ændringer ændrer, hvad du er villig til at acceptere, i stedet for at reparere det, curl ikke kunne læse, og ændringen overlever ofte hændelsen.

Referenceværket for tallene er curl-fejlkataloget, og det er kort nok til at læse grundigt én gang.

Trin 5: download, kig, og kør så

Hent installatøren til en fil i stedet for at pipe den ind i en shell i samme kommando. Den ene ændring adskiller en overførsel, du kan inspicere, fra kode, der kører med dine privilegier.

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

Kontroller, at svaret er det script, du forventede, og ikke en HTML-fejlside, en omdirigeringsmeddelelse eller en tom fil. Hvis udgiveren leverer en kontrolsum eller signatur, skal du verificere den gennem deres dokumenterede udgivelsesproces i stedet for en værdi, der citeres i samme forumtråd.

Husk, hvad HTTPS gjorde, og hvad det ikke gjorde. Det autentificerede transporten til den vært, du kontaktede; det gennemgik ikke scriptets indhold, og det fortæller dig ikke, om udgiveren er troværdig.

Trin 6: hold installationstrinnene adskilt

At downloade filen, installere klienten, konfigurere tunnelen og validere ruter er fire operationer med fire forskellige fejltilstande. At gøre dem én ad gangen betyder, at en fejl senere i rækken har én oplagt årsag i stedet for fire kandidater.

Hvis installationen lykkes, og tunnelen kommer op, skal du kontrollere ruterne og én rigtig destination, før du lukker sagen. Curl-fejlen er rettet, når en almindelig curl -I https://example.invalid virker igen, ikke når installatøren holder op med at klage.