curl-feil 77: sertifikatverifiseringsplasseringer ved en VPN-installasjon

Du limer inn installatørens énlinjekommando fra en veiledning, trykker Enter og får curl: (77). Meldingen nevner sertifikatverifiseringsplasseringer, så instinktet er å anta at VPN-leverandørens sertifikat er ødelagt og gripe etter et flagg som hopper over verifiseringen. Den lesningen er feil, og å handle på den gjør et lokalt filproblem til en sikkerhetsbeslutning. La oss gå gjennom det fra begynnelsen.

Trinn 1: les hva tallet betyr

Feil 77 handler om den lokale CA-inndataen: curl kunne ikke lese eller laste sertifikatmaterialet det ble bedt om å stole på. Feil 60 er den om motparten, der serverens kjede ikke validerer. De står side om side i veiledninger og betyr det motsatte.

Hvis utdataene dine sier 77, var serveren aldri problemet. Klienten kunne ikke åpne filen den ville bruke til kontrollen, og det er et sti-, tillatelses- eller pakkeproblem på maskinen din.

Trinn 2: les kommandoen du kopierte

Kopierte kommandoer skjuler tegn. Liten -l er --list-only, som gjelder opplisting av protokoller. Stor -L er --location, som følger en HTTP-omdirigering. De er ikke alternative stavemåter, og en veiledning som skriver den ene mens den beskriver den andre, sender folk ned en omdirigeringsvei som aldri var ment.

Å følge en omdirigering reparerer ikke en sti i tillitslageret, og det beviser ikke at den endelige verten er utgiveren du mente. Hvis kommandoen kom fra et foruminnlegg, skriv den om fra prosjektets egne instruksjoner i stedet for å stole på innlimingen.

Trinn 3: finn ut hvilken CA-inndata den byggingen bruker

Begynn med å identifisere binærfilen, fordi svaret avhenger av hvordan den ble kompilert:

curl --version

Noter versjonen og TLS-backenden. En bygging med et innfødt tillitslager leser systemlageret gjennom TLS-biblioteket, mens en bygging rettet mot en bunt leser en fil. Et eksplisitt --cacert, en CURL_CA_BUNDLE-innstilling eller en shell-wrapper kan overstyre begge, så en pakkeinstallasjon berører kanskje ikke filen som faktisk feiler.

For et filbasert lager, sjekk tre ting i rekkefølge: finnes stien, kan kontoen som kaller kommandoen lese den, og inneholder den CA-materialet du forventer. En bunt med feil tillatelser feiler på samme måte som en som mangler, og begge feiler før noen nettverkssamtale om serveren finner sted.

Trinn 4: reparer inndataen, ikke verifiseringen

Gjenopprett den støttede tillitskonfigurasjonen gjennom den som eier den: distribusjonspakken, konfigurasjonsstyringen din eller miljøvariabelen som er dokumentert. Målet er en lesbar og korrekt CA-inndata for den binærfilen.

Ikke bytt URL-en til HTTP, ikke legg til --insecure, og ikke stol på et sertifikat som er kopiert fra en uforklart nedlasting. Hver av disse endringene endrer hva du er villig til å godta i stedet for å reparere det curl ikke kunne lese, og endringen overlever ofte hendelsen.

Referansen for tallene er curl-feilkatalogen, og den er kort nok til å leses skikkelig én gang.

Trinn 5: last ned, se, og kjør deretter

Hent installatøren til en fil i stedet for å pipe den inn i et shell i samme kommando. Den ene endringen skiller en overføring du kan inspisere fra kode som kjører med privilegiene 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 forventet og ikke en HTML-feilside, et omdirigeringsvarsel eller en tom fil. Hvis utgiveren tilbyr en sjekksum eller signatur, verifiser den gjennom deres dokumenterte utgivelsesprosess og ikke en verdi som er sitert i samme forumtråd.

Husk hva HTTPS gjorde og ikke gjorde. Det autentiserte transporten til verten du kontaktet; det gjennomgikk ikke skriptets innhold og forteller deg ikke om utgiveren er pålitelig.

Trinn 6: hold installasjonstrinnene adskilt

Å laste ned filen, installere klienten, konfigurere tunnelen og validere ruter er fire operasjoner med fire forskjellige feilmodi. Å gjøre dem én om gangen betyr at en feil senere i sekvensen har én åpenbar årsak i stedet for fire kandidater.

Hvis installasjonen lykkes og tunnelen kommer opp, verifiser rutene og én ekte destinasjon før du lukker saken. Curl-feilen er rettet når en vanlig curl -I https://example.invalid virker igjen, ikke når installatøren slutter å klage.