Uzu vian ekzistantan entreprenan CA por OpenVPN-aj kunuloj

Nenio en OpenVPN postulas, ke la atestilo venas de Easy-RSA, kaj floto, kiu jam havas organizan PKI, kutime ne devus konstrui duan. La vera laboro estas ne elekti ilon, sed decidi, kion signifas la eldonitaj identecoj, kiujn kunulojn la tunelo akceptas, kaj kiel renovigo kaj revoko atingas la kontrolanton. Trairu la kvin paŝojn sube laŭ ordo, ĉar posta paŝo ne povas ripari rolan decidon faritan en la unua.

Eldonu du rolojn anstataŭ unu komuna identeco

Ĉiu kunulo bezonas sian propran atestilon kaj kongruan privatan ŝlosilon. Petu de la PKI-teamo servilan identecon kun servila uzo kaj apartajn klientajn identecojn kun klienta uzo, por ke la tunelo povu distingi la du dum la manpremo.

Rezistu la fuĝvojojn, kiuj aperas sub templimo-premo. Ŝlosilo de retservilo kopiita al tekokomputiloj forviŝas la distingon, sur kiu la rola kontrolo dependas, kaj CA-subskriba ŝlosilo instalita sur VPN-finpunkto transformas unu kompromititan gastigon en kompromititan hierarkion. PKCS12-pakaĵo povas porti finpunktan ŝlosilon kaj ĝian ĉenon, sed ĝi neniam donas permeson reuzi tiun identecon en alia rolo.

Konektu la fido-enigojn sur ĉiu flanko

La kliento kaj la servilo bezonas ĉiu sian fid-ankron, sian propran identecon kaj eksplicitan rol-atendon. Klienta fragmento, kiu deklaras ĉiujn tri, aspektas jene.

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

La servila flanko spegulas ĝin per remote-cert-tls client kaj sia propra atestilo, kaj tio estas kio malhelpas, ke klienta atestilo estu akceptita kiel servilo. La nomkontrolo estas decido aparta de la rola kontrolo. Legu la deplojitan agordon por vidi, kiun kampon oni komparas, anstataŭ supozi retumilan gastig-noman kongruon. Ambaŭ flankoj ankaŭ devus eksplicite diri, kiun eldonanton ili fidas, ĉar komuna dosier-pado tra la floto ne estas la sama afero kiel komuna politiko.

Liveru mezajn atestilojn sen larĝigi la fidon

La du flankoj ne devas dividi unu eldonan ĉenon. Kiam kunulo prezentas atestilon subskribitan de meza atestilo, la kontrolanta flanko bezonas tiun mezan atestilon disponebla, kaj OpenVPN distingas la fid-ankran enigon de la pliaj atestiloj uzataj por kompletigi loke prezentitan ĉenon. La TLS-opcia referenco de OpenVPN 2.6 dokumentas ambaŭ.

Meza CA ne estas esence problemo, sed larĝa entreprena radiko enĵetita en la fido-kolekton estas. Ju pli larĝa la ankro, des pli da atestiloj trapasas la ĉenan teston, kaj rola kontrolo ne igas tion listo de rajtigitaj dungitoj. Mallarĝigu la ankron al la eldonanto, kiu fakte subskribas VPN-identecojn, kie la hierarkio permesas. Se ne, dokumentu la pli larĝan ankron kiel intence akceptitan riskon anstataŭ lasi ĝin implica.

Interkonsentu kun la PKI-teamo pri tio, kiel renovigo kaj revoko atingas la VPN-kontrolantojn, inkluzive kiuj eldonantoj gravas kaj kiu publikigas la liston. CRL-distribua punkto enigita en atestilon estas instrukcio, ne pruvo ke iu akiris ĝin.

Decidu, kiel revoko fakte alvenas

crl-verify igas la kontrolanton konsulti dosieron aŭ finpunkton, kaj tiu aranĝo bezonas posedanton kaj refreŝigan padon. Listo kopiita unufoje dum deplojo silente ĉesas protekti vin la unuan fojon, kiam atestilo estas revokita.

Notu la atendatan disvastiĝan tempon kaj testu ĝin per atestilo, kiun vi pretas revoki. Se la listo ne povas esti refreŝigita sur la VPN-gastigo, la alternativo estas pli mallonga valideco-periodo plus renoviga procezo, kiu fakte funkcias, ne supozo ke revoko funkcias ĉar ekzistas URL.

Pruvu akcepton per reala kliento

Konektu klienton, kiu devus esti permesata, kaj konfirmu la intertraktitajn atestildetalojn en la protokolo. Poste provu la kazojn, kiuj devas malsukcesi: klienta atestilo prezentita kiel servilo, atestilo de eldonanto ekster la fid-ankro, kaj revokita atestilo se vi havas unu spare.

Registru la akceptitan eldonanton, la rolan kontrolon kaj la revokan fonton apud la profilo. Tiu registro estas kion la sekva inĝeniero bezonas, kiam aparato, kiu funkciis pasintmonate, ĉesas konekti, kaj ĝi ankaŭ estas la pruvo, ke la entreprena CA estas uzata ene de dokumentitaj akceptolimoj anstataŭ kiel fid-deponejo por ĝeneralaj celoj.