curl-fout 77: sertifikaatverifikasielys by 'n VPN-installasie

Jy plak die installateerder se eenreël-opdrag uit ’n handleiding, druk Enter en kry curl: (77). Die boodskap noem sertifikaatverifikasielys, so die instink is om aan te neem die VPN-verskaffer se sertifikaat is stukkend en na ’n vlag te gryp wat verifikasie oorslaan. Daardie lees is verkeerd, en om daarvolgens op te tree verander ’n plaaslike lêerprobleem in ’n sekuriteitsbesluit. Kom stap dit van die begin af terug.

Stap 1: lees wat die nommer beteken

Fout 77 gaan oor die plaaslike CA-invoer: curl kon nie die sertifikaatmateriaal lees of laai wat hy moes vertrou nie. Fout 60 is die een oor die eweknie, waar die bediener se ketting nie valideer nie. Hulle staan in handleidings langs mekaar en beteken teenoorgestelde dinge.

As jou uitset 77 sê, was die bediener nooit die probleem nie. Die kliënt kon nie die lêer oopmaak wat hy vir die kontrolering wou gebruik nie, en dit is ’n pad-, toestemmings- of verpakkingsprobleem op jou masjien.

Stap 2: lees die opdrag wat jy gekopieer het

Gekopieerde opdragte versteek karakters. Kleinletter -l is --list-only, wat op die lys van protokolle van toepassing is. Hoofletter -L is --location, wat ’n HTTP-aanstuur volg. Hulle is nie alternatiewe spellings nie, en ’n handleiding wat die een skryf terwyl dit die ander beskryf, stuur mense op ’n aanstuurpad af wat nooit bedoel was nie.

Om ’n aanstuur te volg maak nie ’n trust-store-pad reg nie, en dit bewys nie dat die finale gasheer die uitgewer is wat jy bedoel het nie. As die opdrag uit ’n forumpos kom, tik dit eerder oor uit die projek se eie instruksies as om die plakstrokie te vertrou.

Stap 3: vind watter CA-invoer daardie bou gebruik

Begin deur die binary te identifiseer, want die antwoord hang daarvan af hoe dit saamgestel is:

curl --version

Teken die weergawe en die TLS-agterkant aan. ’n Bou wat ’n inheemse trust store gebruik, lees die stelselstore deur die TLS-biblioteek, terwyl ’n bou wat na ’n bundel wys ’n lêer lees. ’n Eksplisiete --cacert, ’n CURL_CA_BUNDLE-instelling of ’n shell-wrapper kan enigeen van die twee oorheers, so ’n pakketinstallasie raak dalk nie die lêer wat werklik faal nie.

Vir ’n lêergebaseerde store, kontroleer drie dinge in volgorde: bestaan die pad, kan die roepende rekening dit lees, en bevat dit die CA-materiaal wat jy verwag. ’n Bundel met die verkeerde toestemmings faal net soos een wat ontbreek, en albei faal voordat enige netwerkgesprek oor die bediener plaasvind.

Stap 4: herstel die invoer, nie die verifikasie nie

Herstel die ondersteunde trust-konfigurasie deur wie dit ook al besit: die verspreidingspakket, jou konfigurasiebestuur, of die gedokumenteerde omgewingsveranderlike. Die doel is ’n leesbare, korrekte CA-invoer vir daardie binary.

Moenie die URL na HTTP skakel nie, voeg nie --insecure by nie, en vertrou nie ’n sertifikaat wat uit ’n onverklaarde aflaai gekopieer is nie. Elkeen van daardie veranderinge verander wat jy bereid is om te aanvaar in plaas daarvan om reg te maak wat curl nie kon lees nie, en die verandering oorleef gewoonlik die voorval.

Die curl-foutkatalogus is die verwysing vir die nommers, en dit is kort genoeg om een keer behoorlik te lees.

Stap 5: laai af, kyk, en voer dan uit

Haal die installateerder na ’n lêer eerder as om dit in dieselfde opdrag in ’n shell te pyp. Daardie enkele verandering skei ’n oordrag wat jy kan ondersoek van kode wat met jou voorregte loop.

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

Kontroleer dat die antwoord die script is wat jy verwag het en nie ’n HTML-foutbladsy, ’n aanstuurkennisgewing of ’n leë lêer nie. As die uitgewer ’n kontrolesom of handtekening verskaf, verifieer dit deur hulle gedokumenteerde vrystellingsproses eerder as ’n waarde wat in dieselfde forumdraad aangehaal word.

Onthou wat HTTPS gedoen het en wat nie. Dit het die vervoer na die gasheer wat jy gekontak het, geauthentiseer; dit het nie die script se inhoud nagegaan nie, en dit sê nie vir jou of die uitgewer betroubaar is nie.

Stap 6: hou die installasiestappe apart

Om die lêer af te laai, die kliënt te installeer, die tonnel te konfigureer en roetes te valideer is vier bewerkings met vier verskillende faalmodusse. Om dit een op ’n slag te doen beteken ’n fout later in die reeks het een ooglopende oorsaak eerder as vier kandidate.

As die installasie slaag en die tonnel kom op, verifieer die roetes en een werklike bestemming voordat jy die kaartjie sluit. Die curl-fout is reg wanneer ’n gewone curl -I https://example.invalid weer werk, nie wanneer die installateerder ophou kla nie.