curl-fout 77: certificaatverificatielocaties bij een VPN-installatie
Fout 77 is een lokaal CA-invoerprobleem, geen slecht servercertificaat. Vind het vertrouwensbestand dat curl leest, herstel het en bekijk het script voordat u het uitvoert.
U plakt de installatieopdracht van één regel uit een handleiding, drukt op Enter en krijgt curl: (77). Het bericht noemt certificaatverificatielocaties, dus de neiging is om aan te nemen dat het certificaat van de VPN-provider kapot is en naar een optie te grijpen die verificatie overslaat. Die lezing is onjuist, en ernaar handelen maakt van een lokaal bestandsprobleem een beveiligingsbeslissing. Laten we het vanaf het begin teruglopen.
Stap 1: lees wat het nummer betekent
Fout 77 gaat over de lokale CA-invoer: curl kon het certificaatmateriaal dat het moest vertrouwen niet lezen of laden. Fout 60 is degene over de tegenpartij, waarbij de keten van de server niet valideert. Ze staan in handleidingen naast elkaar en betekenen het tegenovergestelde.
Als uw uitvoer 77 zegt, was de server nooit het probleem. De client kon het bestand dat hij voor de controle wilde gebruiken niet openen, en dat is een pad-, rechten- of verpakkingsprobleem op uw machine.
Stap 2: lees de opdracht die u hebt gekopieerd
Gekopieerde opdrachten verbergen tekens. Kleine -l is --list-only, dat geldt voor het opsommen van protocollen. Grote -L is --location, dat een HTTP-omleiding volgt. Het zijn geen alternatieve spellingen, en een handleiding die het ene schrijft terwijl ze het andere beschrijft, stuurt mensen een omleidingspad op dat nooit bedoeld was.
Een omleiding volgen herstelt geen pad van een vertrouwensopslag en bewijst niet dat de uiteindelijke host de uitgever is die u bedoelde. Als de opdracht uit een forumbericht komt, typ hem dan over uit de eigen instructies van het project in plaats van de plaksel te vertrouwen.
Stap 3: zoek uit welke CA-invoer die build gebruikt
Begin met het identificeren van het binaire bestand, want het antwoord hangt af van hoe het is gecompileerd:
curl --versionNoteer de versie en de TLS-backend. Een build met een native vertrouwensopslag leest de systeemopslag via de TLS-bibliotheek, terwijl een build die naar een bundel wijst een bestand leest. Een expliciete --cacert, een CURL_CA_BUNDLE-instelling of een shell-wrapper kunnen beide overschrijven, dus een pakketinstallatie raakt misschien niet het bestand dat feitelijk faalt.
Controleer voor een bestandsopslag drie dingen in volgorde: bestaat het pad, kan het account dat de opdracht aanroept het lezen, en bevat het het CA-materiaal dat u verwacht. Een bundel met verkeerde rechten faalt precies zoals een ontbrekende, en beide falen voordat er enig netwerkgesprek over de server plaatsvindt.
Stap 4: herstel de invoer, niet de verificatie
Herstel de ondersteunde vertrouwensconfiguratie via degene die er eigenaar van is: het distributiepakket, uw configuratiebeheer of de gedocumenteerde omgevingsvariabele. Het doel is een leesbare, correcte CA-invoer voor dat binaire bestand.
Schakel de URL niet om naar HTTP, voeg geen --insecure toe en vertrouw geen certificaat dat uit een onverklaarde download is gekopieerd. Elk van die wijzigingen verandert wat u bereid bent te accepteren in plaats van te herstellen wat curl niet kon lezen, en de wijziging overleeft meestal het incident.
De referentie voor de nummers is de curl-foutcatalogus, en die is kort genoeg om één keer goed te lezen.
Stap 5: download, kijk en voer dan uit
Haal de installer naar een bestand in plaats van hem in dezelfde opdracht naar een shell te pipen. Die ene wijziging scheidt een overdracht die u kunt inspecteren van code die met uw rechten draait.
curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.shControleer dat het antwoord het script is dat u verwachtte en niet een HTML-foutpagina, een omleidingsmelding of een leeg bestand. Als de uitgever een controlesom of handtekening levert, verifieer die dan via hun gedocumenteerde releaseproces en niet via een waarde die in dezelfde forummethread wordt geciteerd.
Onthoud wat HTTPS wel en niet deed. Het authenticeerde het transport naar de host die u benaderde; het bekeek de inhoud van het script niet en het vertelt u niet of de uitgever betrouwbaar is.
Stap 6: houd de installatiestappen gescheiden
Het bestand downloaden, de client installeren, de tunnel configureren en de routes valideren zijn vier bewerkingen met vier verschillende faalwijzen. Ze één voor één doen betekent dat een fout later in de reeks één duidelijke oorzaak heeft in plaats van vier kandidaten.
Als de installatie slaagt en de tunnel komt op, verifieer dan de routes en één echte bestemming voordat u het ticket sluit. De curl-fout is verholpen wanneer een gewone curl -I https://example.invalid weer werkt, niet wanneer de installer ophoudt met klagen.