curl-feil 77: sertifikatverifiseringsstader ved ein VPN-installasjon

Du limer inn einlinjekommandoen til installatøren frå ei rettleing, trykkjer Enter og får curl: (77). Meldinga nemner sertifikatverifiseringsstader, så instinktet er å anta at sertifikatet til VPN-leverandøren er øydelagt og gripe etter eit flagg som hoppar over verifiseringa. Den lesinga er feil, og å handle etter henne gjer eit lokalt filproblem til ei sikkerheitsavgjerd. Lat oss gå gjennom det frå byrjinga.

Steg 1: les kva talet tyder

Feil 77 handlar om den lokale CA-inndataen: curl kunne ikkje lese eller laste sertifikatmaterialet det vart bede om å stole på. Feil 60 er den om motparten, der kjeda til serveren ikkje validerer. Dei står side om side i rettleingar og tyder det motsette.

Viss utdataa dine seier 77, var serveren aldri problemet. Klienten kunne ikkje opne fila han ville bruke til kontrollen, og det er eit sti-, løyve- eller pakkeproblem på maskina di.

Steg 2: les kommandoen du kopierte

Kopierte kommandoar gøymer teikn. Liten -l er --list-only, som gjeld opplisting av protokollar. Stor -L er --location, som følgjer ei HTTP-omdirigering. Dei er ikkje alternative stavemåtar, og ei rettleing som skriv den eine medan ho skildrar den andre, sender folk ned ein omdirigeringsveg som aldri var meint.

Å følgje ei omdirigering reparerer ikkje ein sti i eit tillitslager, og det bevisar ikkje at den endelege verten er utgjevaren du meinte. Viss kommandoen kom frå eit foruminnlegg, skriv han om frå prosjektet sine eigne instruksjonar i staden for å stole på innliminga.

Steg 3: finn ut kva CA-inndata den bygginga brukar

Byrja med å identifisere binærfilen, fordi svaret avheng av korleis han vart kompilert:

curl --version

Noter versjonen og TLS-backenden. Ei bygging med eit innfødd tillitslager les systemlageret gjennom TLS-biblioteket, medan ei bygging retta mot ein bunt les ei fil. Eit eksplisitt --cacert, ei CURL_CA_BUNDLE-innstilling eller ein shell-wrapper kan overstyre begge, så ein pakkeinstallasjon rører kanskje ikkje fila som faktisk feilar.

For eit filbasert lager, sjekk tre ting i rekkefølgje: finst stien, kan kontoen som kallar kommandoen lese han, og inneheld han CA-materialet du forventar. Ein bunt med feil løyve feilar på same måte som ein som manglar, og begge feilar før noko nettverkssamtale om serveren finn stad.

Steg 4: reparer inndataen, ikkje verifiseringa

Gjenopprett den støtta tillitskonfigurasjonen gjennom den som eig han: distribusjonspakken, konfigurasjonsstyringa di eller miljøvariabelen som er dokumentert. Målet er ein lesbar og korrekt CA-inndata for den binærfilen.

Ikkje byt URL-en til HTTP, ikkje legg til --insecure, og ikkje stol på eit sertifikat som er kopiert frå ei uforklart nedlasting. Kvar av desse endringane endrar kva du er villig til å godta i staden for å reparere det curl ikkje kunne lese, og endringa overlever ofte hendinga.

Referansen for tala er curl-feilkatalogen, og han er kort nok til å lesast skikkeleg éin gong.

Steg 5: last ned, sjå, og køyr deretter

Hent installatøren til ei fil i staden for å pipe han inn i eit shell i same kommando. Den eine endringa skil ei overføring du kan granske frå kode som køyrer med privilegia dine.

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 skriptet du forventa og ikkje ei HTML-feilside, eit omdirigeringsvarsel eller ei tom fil. Viss utgjevaren tilbyr ein sjekksum eller signatur, verifiser han gjennom den dokumenterte utgivingsprosessen deira og ikkje ein verdi som er sitert i same forumtråd.

Hugs kva HTTPS gjorde og ikkje gjorde. Det autentiserte transporten til verten du kontakta; det gjekk ikkje gjennom innhaldet i skriptet og fortel deg ikkje om utgjevaren er påliteleg.

Steg 6: hald installasjonstrinna åtskilde

Å laste ned fila, installere klienten, konfigurere tunnelen og validere rutene er fire operasjonar med fire ulike feilmodus. Å gjere dei éin om gongen betyr at ein feil seinare i sekvensen har éin openberr årsak i staden for fire kandidatar.

Viss installasjonen lykkast og tunnelen kjem opp, verifiser rutene og éin ekte destinasjon før du lukkar saka. Curl-feilen er retta når ein vanleg curl -I https://example.invalid verkar igjen, ikkje når installatøren sluttar å klage.