Ang profile ng OpenVPN ay may tatlong bloke ng sertipiko: alin ang lihim?

Binubuksan mo ang .ovpn file para baguhin ang isang linya at nakakita ka ng tatlong bloke ng base64 na lahat ay mukhang kredensyal. Ang isa ay ligtas na ilathala, ang isa ay kasing-sensitibo ng password, at ang isa ay pampublikong susi na walang ibig sabihin maliban kung may ibang pinirmahan gamit ang pares nito. Idinidikit ng mga tao ang buong file sa isang thread ng suporta dahil mukhang mapapalitan ang mga bloke, at ganoon napupunta ang susi ng kliyente sa pampublikong archive. Ang pagkilala kung aling bloke ang gumagawa ng ano ay nagpapaliwanag sa karamihan ng kalituhan tungkol sa mga profile na ito, at sinasabi rin nito kung aling mga pagkabigo ang dapat mong ayusin mismo.

Isang file, tatlong bloke, magkaibang gawain

Ang karaniwang profile ay naglalagay ng bloke ng ca, bloke ng cert at bloke ng key sa pagitan ng mga marker na BEGIN at END, o tumutukoy sa parehong tatlo bilang hiwalay na file. May mga profile na nagdaragdag ng ikaapat na bloke para sa susi ng tls-auth o tls-crypt, na isang pinagsasaluhang lihim at hindi sertipiko. Binabasa ng kliyente ang bawat bloke ayon sa direktiba na nagpangalan dito, kaya mas mahalaga ang mga label kaysa sa pagkakasunod-sunod ng paglitaw.

Ituring na sensitibo ang buong profile hanggang sa talagang tumingin ka sa loob. Ang pampublikong sertipiko at pribadong susi ay maaaring magkalayo ng ilang linya sa parehong file, at ang screenshot na may header ay maaaring maglaman ng pareho. Hindi rin maaasahan ang manu-manong pagtakip sa nakikitang base64, dahil ang bahagyang bloke ay naglalabas pa rin ng metadata ng sertipiko na nagpapangalan sa deployment mo. Ang pagkopya ng tatlong direktiba nang walang halaga nito ay karaniwang sapat para makapagtanong ng kapaki-pakinabang na tanong.

Ang mga direktiba sa paligid ng mga bloke ang nagtatakda kung paano ginagamit ang mga ito. Baguhin ang ca at ang kliyente ay nagtitiwala sa ibang awtoridad; baguhin ang cert nang hindi binabago ang key at nabibigo ang handshake sa isang pagkakaiba na walang kinalaman sa pagtitiwala.

Ang bloke ng CA ay pampubliko, ang susi ng CA ay hindi kailanman

Ang awtoridad ng sertipiko ay pumipirma ng mga sertipikong nagbibigkis ng pampublikong susi sa isang pagkakakilanlan, at ang sariling sertipiko nito ang angkla na ginagamit ng kliyente para magpasya kung mapagkakatiwalaan ang isang kadena. Ang sertipikong iyon ay pampubliko ayon sa disenyo: normal na isama ito sa bawat profile, at iyon ang dahilan kung bakit gumagana ang self-signed na deployment nang walang komersyal na awtoridad.

Ang hindi dapat kailanman lumitaw sa profile ng kliyente ay ang pribadong susi ng pagpirma ng awtoridad. Hindi ito kailangan ng kliyente para sa anumang pagpapatunay, at ang pagkakaroon nito ay nangangahulugan na kahit sino ang may profile ay makakagawa ng bagong pagkakakilanlan para sa buong deployment.

Ang pagtitiwala sa isang awtoridad ay mas makitid din kaysa sa tunog nito. Ang kliyenteng tumatanggap ng anumang sertipikong pinirmahan ng CA ay tatanggap pa rin ng sertipikong inisyu para sa ibang serbisyo sa parehong CA. Ang mga opsiyong nag-aayos ng inaasahang papel o pangalan ng server ay nagsasara ng puwang na iyon, at ang Sanggunian ng mga opsiyon ng TLS ay naglilista ng mga direktiba ng beripikasyon na gumagawa nito.

Ang mga sertipiko ng server at kliyente ay tumuturo sa magkasalungat na direksyon

Ang sertipiko ng server ay ang sinusuri ng kliyente para kumpirmahin na naabot nito ang tamang endpoint. Ang sertipiko ng kliyente mo ay kabaligtaran: ginagamit ito ng server para magpasya na ang device o user na ito ay isang nairehistro nito. Parehong format, magkasalungat na direksyon ng pagtitiwala.

Ang address ay hindi pagkakakilanlan. Ang maabot ang tamang IP ay walang pinatutunayan tungkol sa kung sino ang sumagot, kaya ang pagsuri ng hostname o pangalan ng sertipiko ay kabilang pa rin sa profile. Ang password ng account ay hindi rin tahimik na pumapalit sa kinakailangang sertipiko ng kliyente, dahil ang dalawa ay sinusuri sa magkaibang yugto at ang deployment ay maaaring mangailangan ng pareho.

Ang pribadong susi ng kliyente ang bahaging dapat manatiling pribado. Kung maaaring nalantad ito, ang pagtanggal ng file sa laptop mo ay walang binabago sa server, na patuloy na tatanggap sa kaukulang sertipiko hanggang bawiin ito ng operator. Ang hilingin sa operator na palitan o bawiin ang pagkakakilanlang iyon ang tanging lunas na naglalakbay kasama mo.

Dalawang prompt na magkamukha at hindi

Ang susing nakaimbak sa naka-encrypt na anyo ay humihingi ng passphrase bago ito magamit ng kliyente. Maaaring humingi nang hiwalay ang serbisyo ng VPN ng password ng account, at ang dalawang prompt ay maaaring lumitaw na may pagitan ng ilang segundo na halos pareho ang pananalita. Pinoprotektahan ng passphrase ang isang file sa disk mo; pinatutunayan ng password ang isang account sa server. Ang pagpapalito sa dalawa ay nagpapadala ng tao sa mga pag-reset na imposibleng makatulong.

Basahin ang prompt bago mag-reset ng anuman. Ang pag-reset ng password ng account ay walang nagagawa para sa nakalimutang passphrase ng susi, binawi o nag-expire na sertipiko, at ang pag-reset ng password kapag beripikasyon ng sertipiko ang pagkabigo ay ginagawang kaso ng suporta ang dalawang minutong pag-aayos. Kung binanggit ng reklamo ang mga petsa ng bisa, suriin muna ang orasan ng device at pagkatapos ang sariling saklaw ng pinangalanang sertipiko.

Kapag talagang nag-expire na ang sertipiko, ang kapalit ay dapat magmula sa nag-isyu nito. Ang susing pag-aari ng iba ay hindi landas ng pag-renew, at ang hiramin ang gumaganang profile mula sa katrabaho ay gayon din.

Ano ang pinatutunayan ng malinis na handshake at ano ang hindi

Ang maabot ang kumpletong TLS handshake ay nangangahulugan na nanatili ang naka-configure na ugnayan ng pagkakakilanlan: ang sertipiko ng server ay kumadena sa CA mo at tinanggap ang sertipiko mo. Wala itong sinasabi tungkol sa patakaran ng pag-log ng operator, at wala rin tungkol sa kung gagana ang mga aplikasyon mo kapag nakaangat na ang tunnel.

Ang mga ruta at DNS ay mga huling yugto ng koneksyon, kaya ang hindi maabot na intranet host pagkatapos ng matagumpay na pag-login ay problema sa pagkakakonekta at hindi sa sertipiko. Trabahoan ang layer na iyon kaysa palitan ang mga kredensyal, at panatilihing magkasama ang pinagmulan ng profile, ang pribadong materyal nito at ang mga pagsusuri ng pagkakakilanlan nito kapag ibinibigay mo ito sa iba.