OpenVPN profil ima tri bloka certifikata: koji je tajni?

Otvorite .ovpn datoteku da promijenite jednu liniju i nađete tri bloka base64 koji svi izgledaju kao akreditivi. Jedan je siguran za objavljivanje, jedan je osjetljiv kao lozinka, a jedan je javni ključ koji ništa ne znači ako nešto drugo nije potpisano njegovim parom. Ljudi zalijepe cijelu datoteku u temu podrške jer blokovi izgledaju zamjenjivo, i tako klijentski ključ završi u javnom arhivu. Razvrstavanje koji blok šta radi objašnjava većinu zabune oko ovih profila i govori vam koje kvarove trebate popraviti sami.

Jedna datoteka, tri bloka, različiti poslovi

Tipičan profil ugrađuje ca blok, cert blok i key blok između oznaka BEGIN i END ili upućuje na ista tri kao na zasebne datoteke. Neki profili dodaju četvrti blok za tls-auth ili tls-crypt ključ, koji je zajednička tajna, a ne certifikat. Klijent čita svaki blok prema direktivi koja ga imenuje, pa su oznake važnije od redoslijeda pojavljivanja.

Tretirajte sastavljeni profil kao osjetljiv dok zaista ne pogledate unutra. Javni certifikat i privatni ključ mogu stajati nekoliko redova jedan od drugog u istoj datoteci, a snimak ekrana koji uključuje zaglavlje može uključivati oboje. Ručno zamućivanje vidljivog base64 također je nepouzdano, jer djelimičan blok ipak odaje metapodatke certifikata koji imenuju vašu instalaciju. Kopiranje tri direktive bez njihovih vrijednosti obično je dovoljno za korisno pitanje.

Direktive oko blokova odlučuju kako se koriste. Promijenite ca i klijent vjeruje drugom tijelu; promijenite cert bez promjene key i rukovanje pada uz nepodudarnost koja nema veze s povjerenjem.

CA blok je javan, CA ključ nikada

Certifikacijsko tijelo potpisuje certifikate koji vežu javni ključ za identitet, a njegov vlastiti certifikat je sidro pomoću kojeg klijent odlučuje je li lanac pouzdan. Taj certifikat je javan po dizajnu: slanje unutar svakog profila je normalno i upravo zato samopotpisana instalacija može raditi bez komercijalnog tijela.

Ono što nikada ne smije stajati u klijentskom profilu je privatni ključ za potpisivanje tijela. Klijentu ne treba ni za kakvu provjeru, a njegovo prisustvo znači da svako ko drži profil može stvarati nove identitete za cijelu instalaciju.

Vjerovanje tijelu uže je nego što zvuči. Klijent koji prihvata bilo koji certifikat koji je potpisao CA prihvatit će i certifikat izdat za drugu uslugu na istom CA. Opcije koje fiksiraju očekivanu ulogu ili ime servera zatvaraju tu prazninu, a Pregled TLS opcija navodi direktive provjere koje to rade.

Serverski i klijentski certifikati pokazuju u suprotnim smjerovima

Serverski certifikat je ono što klijent pregleda da potvrdi da je stigao na pravu krajnju točku. Vaš klijentski certifikat radi obrnuto: server ga koristi da odluči da je ovaj uređaj ili korisnik onaj koji je upisao. Isti format, suprotan smjer povjerenja.

Adresa nije identitet. Dolazak na pravu IP adresu ništa ne dokazuje o tome ko je odgovorio, zato provjera imena hosta ili imena certifikata i dalje pripada profilu. Ni lozinka računa ne zamjenjuje tiho potrebni klijentski certifikat, jer se oboje provjerava u različitim fazama i instalacija može zahtijevati oboje.

Privatni ključ klijenta je dio koji mora ostati privatan. Ako je mogao biti izložen, brisanje datoteke s vašeg laptopa ne mijenja ništa na serveru, koji će nastaviti prihvatati odgovarajući certifikat dok ga operator ne opozove. Molba operatoru da zamijeni ili opozove taj identitet jedini je popravak koji putuje s vama.

Dva upita koja izgledaju identično i nisu

Ključ pohranjen u šifriranom obliku traži frazu za pristup prije nego što ga klijent može koristiti. VPN usluga može odvojeno tražiti lozinku računa, a dva upita mogu se pojaviti u razmaku od nekoliko sekundi s gotovo istom formulacijom. Fraza štiti datoteku na vašem disku; lozinka dokazuje račun serveru. Miješanje njih dvoje vodi ljude na resetovanja lozinke koja nikako ne mogu pomoći.

Pročitajte upit prije nego što bilo šta resetujete. Reset lozinke računa ne čini ništa za zaboravljenu ključnu frazu, opozvan ili istekao certifikat, a reset lozinke kada je kvar validacija certifikata pretvara dvominutni popravak u slučaj za podršku. Ako žalba spominje datume valjanosti, prvo provjerite sat uređaja, a zatim vlastiti prozor navedenog certifikata.

Kada je certifikat zaista istekao, zamjena mora doći od onoga ko ga je izdao. Ključ koji pripada nekome drugom nije put obnove, kao ni posuđivanje ispravnog profila od kolege.

Šta čisto rukovanje dokazuje, a šta ne

Dolazak do završenog TLS rukovanja znači da je konfigurisani odnos identiteta izdržao: serverski certifikat se vezao na vaš CA i vaš certifikat je prihvaćen. To ne govori ništa o politici zapisivanja operatora, niti o tome hoće li vaše aplikacije raditi kada tunel bude podignut.

Rute i DNS su kasnije faze veze, pa je nedostupni intranet host nakon uspješne prijave problem povezivanja, a ne certifikata. Radite na tom sloju umjesto da mijenjate akreditive i držite porijeklo profila, njegov privatni materijal i njegove provjere identiteta zajedno kada ga predajete nekome.