curl-fel 77: platser för certifikatverifiering vid en VPN-installation

Du klistrar in installerarens enradskommando från en guide, trycker Enter och får curl: (77). Meddelandet nämner platser för certifikatverifiering, så instinkten är att anta att VPN-leverantörens certifikat är trasigt och gripa efter en flagga som hoppar över verifieringen. Den läsningen är fel, och att agera på den gör ett lokalt filproblem till ett säkerhetsbeslut. Låt oss gå igenom det från början.

Steg 1: läs vad siffran betyder

Fel 77 handlar om den lokala CA-indatan: curl kunde inte läsa eller läsa in certifikatmaterialet som det blev tillsagt att lita på. Fel 60 är det om motparten, där serverns kedja inte validerar. De står sida vid sida i guider och betyder motsatsen.

Om din utdata säger 77 var servern aldrig problemet. Klienten kunde inte öppna filen den ville använda för kontrollen, och det är ett sökvägs-, behörighets- eller paketeringsproblem på din maskin.

Steg 2: läs kommandot du kopierade

Kopierade kommandon döljer tecken. Litet -l är --list-only, som gäller listning av protokoll. Stort -L är --location, som följer en HTTP-omdirigering. De är inte alternativa stavningar, och en guide som skriver den ena medan den beskriver den andra skickar folk nerför en omdirigeringsväg som aldrig var avsedd.

Att följa en omdirigering reparerar inte en sökväg i ett tillitslager, och det bevisar inte att den slutliga värden är den utgivare du menade. Om kommandot kom från ett foruminlägg, skriv om det från projektets egna instruktioner i stället för att lita på inklistringen.

Steg 3: ta reda på vilken CA-indata den byggningen använder

Börja med att identifiera binärfilen, eftersom svaret beror på hur den kompilerades:

curl --version

Notera versionen och TLS-backenden. En byggning med ett inbyggt tillitslager läser systemlagret via TLS-biblioteket, medan en byggning som pekar på ett paket läser en fil. Ett explicit --cacert, en CURL_CA_BUNDLE-inställning eller ett shell-omslag kan åsidosätta båda, så en paketinstallation rör kanske inte filen som faktiskt misslyckas.

För ett filbaserat lager, kontrollera tre saker i ordning: finns sökvägen, kan kontot som anropar kommandot läsa den, och innehåller den det CA-material du förväntar dig. Ett paket med fel behörigheter misslyckas precis som ett som saknas, och båda misslyckas innan något nätverkssamtal om servern sker.

Steg 4: reparera indatan, inte verifieringen

Återställ den stödda tillitskonfigurationen genom den som äger den: distributionspaketet, din konfigurationshantering eller den dokumenterade miljövariabeln. Målet är en läsbar och korrekt CA-indata för den binärfilen.

Byt inte URL:en till HTTP, lägg inte till --insecure, och lita inte på ett certifikat som kopierats från en oförklarad nedladdning. Var och en av dessa ändringar ändrar vad du är villig att acceptera i stället för att reparera det curl inte kunde läsa, och ändringen överlever oftast incidenten.

Referensen för siffrorna är curl-felkatalogen, och den är kort nog att läsas ordentligt en gång.

Steg 5: ladda ner, titta och kör sedan

Hämta installeraren till en fil i stället för att pipa den till ett shell i samma kommando. Den enda ändringen skiljer en överföring du kan granska från kod som körs med dina privilegier.

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

Kontrollera att svaret är skriptet du förväntade dig och inte en HTML-felsida, ett omdirigeringsmeddelande eller en tom fil. Om utgivaren tillhandahåller en kontrollsumma eller signatur, verifiera den genom deras dokumenterade utgivningsprocess och inte ett värde som citeras i samma forumtråd.

Kom ihåg vad HTTPS gjorde och inte gjorde. Det autentiserade transporten till värden du kontaktade; det granskade inte skriptets innehåll och det berättar inte om utgivaren är pålitlig.

Steg 6: håll installationsstegen åtskilda

Att ladda ner filen, installera klienten, konfigurera tunneln och validera rutter är fyra operationer med fyra olika felmoder. Att göra dem en i taget innebär att ett fel senare i sekvensen har en uppenbar orsak i stället för fyra kandidater.

Om installationen lyckas och tunneln kommer upp, verifiera rutterna och en verklig destination innan du stänger ärendet. Curl-felet är åtgärdat när ett vanligt curl -I https://example.invalid fungerar igen, inte när installeraren slutar klaga.