Upotrijebite postojeći korporativni CA za OpenVPN partnere

Ništa u OpenVPN ne zahtijeva da certifikat dolazi iz Easy-RSA, a flota koja već ima organizacijski PKI obično ne bi trebala graditi drugi. Pravi posao nije odabir alata nego odlučivanje što znače izdani identiteti, koje partnere tunel prihvaća i kako obnova i opoziv stižu do verifikatora. Prođite kroz pet koraka u nastavku redom, jer kasniji korak ne može popraviti odluku o ulozi donesenu u prvom.

Izdajte dvije uloge umjesto jednog zajedničkog identiteta

Svaki partner treba vlastiti certifikat i odgovarajući privatni ključ. Zatražite od PKI tima identitet poslužitelja s upotrebom poslužitelja i zasebne identitete klijenata s upotrebom klijenta, kako bi tunel mogao razlikovati njih dvoje tijekom rukovanja.

Oduprite se prečacima koji se pojavljuju pod pritiskom rokova. Kopirani ključ web poslužitelja na prijenosna računala briše razliku na kojoj se temelji provjera uloge, a ključ za potpisivanje CA instaliran na VPN krajnjoj točki pretvara jedan kompromitirani host u kompromitiranu hijerarhiju. Paket PKCS12 može nositi ključ krajnje točke i njegov lanac, ali nikada ne daje dopuštenje za ponovnu upotrebu tog identiteta u drugoj ulozi.

Povežite ulaze povjerenja na svakoj strani

Klijent i poslužitelj trebaju svaki svoju sidrišnu točku povjerenja, vlastiti identitet i izričito očekivanje uloge. Ulomak klijenta koji navodi sve tri stvari izgleda ovako.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Strana poslužitelja to zrcali s remote-cert-tls client i vlastitim certifikatom, i upravo to sprječava da se klijentski certifikat prihvati kao poslužitelj. Provjera naziva zasebna je odluka od provjere uloge. Pročitajte raspoređenu konfiguraciju da vidite koje se polje uspoređuje, umjesto da pretpostavite podudaranje naziva hosta u stilu preglednika. Obje strane također trebaju izričito navesti kojem izdavatelju vjeruju, jer zajednička putanja datoteke u cijeloj floti nije isto što i zajednička politika.

Dostavite posredničke certifikate bez širenja povjerenja

Dvije strane ne moraju dijeliti jedan lanac izdavanja. Kada partner predstavi certifikat potpisan od posredničkog certifikata, strana koja verificira treba taj posrednički certifikat dostupnim, i OpenVPN razlikuje ulaz sidrišne točke povjerenja od dodatnih certifikata koji se koriste za dovršetak lokalno predstavljenog lanca. Referenca TLS opcija za OpenVPN 2.6 dokumentira oboje.

Posrednički CA sam po sebi nije problem, ali široki korporativni korijen ubačen u snop povjerenja jest. Što je sidro šire, to više certifikata prolazi test lanca, a provjera uloge to ne pretvara u popis ovlaštenog osoblja. Suzite sidro na izdavatelja koji stvarno potpisuje VPN identitete gdje hijerarhija to dopušta. Ako ne dopušta, dokumentirajte šire sidro kao namjerno prihvaćen rizik umjesto da ga ostavite implicitnim.

Dogovorite s PKI timom kako obnova i opoziv stižu do VPN verifikatora, uključujući koji su izdavatelji važni i tko objavljuje popis. Točka distribucije CRL-a ugrađena u certifikat je uputa, a ne dokaz da ju je nešto dohvatilo.

Odlučite kako opoziv zapravo stiže

crl-verify navodi verifikator da konzultira datoteku ili krajnju točku, a takav raspored treba vlasnika i put osvježavanja. Popis kopiran jednom tijekom uvođenja tiho prestaje štititi vas prvom prilikom kada se certifikat opozove.

Zapišite očekivano vrijeme širenja i testirajte ga certifikatom koji ste spremni opozvati. Ako se popis ne može osvježiti na VPN hostu, alternativa je kraće razdoblje valjanosti plus proces obnove koji stvarno radi, a ne pretpostavka da opoziv funkcionira jer postoji URL.

Dokažite prihvaćanje stvarnim klijentom

Povežite klijenta kojemu bi trebalo dopustiti i potvrdite pregovorene pojedinosti certifikata u zapisniku. Zatim isprobajte slučajeve koji moraju pasti: klijentski certifikat predstavljen kao poslužitelj, certifikat izdavatelja izvan sidrišne točke povjerenja i opozvani certifikat ako vam je jedan viška.

Zabilježite prihvaćenog izdavatelja, provjeru uloge i izvor opoziva uz profil. Taj je zapis ono što sljedeći inženjer treba kada uređaj koji je prošlog mjeseca radio prestane se povezivati, a ujedno je i dokaz da se korporativni CA koristi unutar dokumentirane granice prihvaćanja, a ne kao odlagalište povjerenja opće namjene.