Aldoni VPN-klienton sen rekonstrui la CA

Vi bezonas ankoraŭ unu atestilon por ankoraŭ unu tekkomputilon, sed la unua lernilo en la serĉrezultoj komenciĝas per komando, kiu forviŝas la PKI-dosierujon. Tiu komando apartenas al la unua agordo, ne al registrado, kaj ĝi kostas al vi la CA-on, la eldonan historion kaj ĉiun klientan profilon, kiu fidis la malnovan eldonanton. La decido estas pli mallarĝa: ĉu la eldonanto ankoraŭ havas uzeblan staton, kaj ĉu la nova aparato konformas al via registrada politiko? Tri kondiĉoj decidas, kaj nur unu pravigas rekonstruon.

Kion rekonstruo vere detruas

Reinicialigo de PKI anstataŭigas la dosierujon per malplena strukturo: nova CA-ŝlosilo kaj atestilo, malplena eldona datumbazo, nova seria nombrilo. Klientoj ne sekvas silente; iliaj profilo fiksas la malnovan CA-on, do ĉiu aparato devas regiŝiĝi denove, kaj neatingeblaj aparatoj permane.

La pli kvieta perdo estas la librotenado. Revokado dependas de tio, ke vi scias, kiujn seriajn numerojn vi eldonis kaj al kiu. Forviŝu la indekson kaj vi ankoraŭ povas subskribi, sed ne plu certe diri, kiujn el la elstaraj atestiloj vi intencis revoki. CA-dosierujo kun atestiloj sen la responda eldonanta stato estas savkopio, kiu restarigas la malĝustan duonon de la sistemo.

Kopii la privatan ŝlosilon de la CA apud la funkcianta servilo estas la alia prenda vojo, kiun oni rifuzu: ĝi faras el subskriba aŭtoritato, kiu devus resti eksterrete, ankoraŭ unu dosieron sur gastiganto kun nefidinda trafiko.

Unua kondiĉo: ĉu la stato de la eldonanto ankoraŭ atingeblas?

Trovu la dosierujon, kiun la servilo vere fidas, antaŭ ol decidi. Komparu la atestilon, kiun la servilo prezentas kiel CA, kun tiu en via PKI-dosierujo per fingrospuro, ne per dosiernomo:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Se la spuroj kongruas, la registrado estas pliiga kaj vi rekonstruu nenion. Se ili malsamas, vi subskribos per CA, kiun la servilo ne fidas: la atestilo instaliĝas pure kaj malsukcesas ĉe la manpremo, kaj tiu eraro estas misdiagnozita kiel klienta fuŝo dum horoj.

Poste serĉu la eldonan staton: la indeksa dosiero, la seria nombrilo kaj la dosiero de la CRL-numero. Se la indekso mankas sed la ŝlosilo pluvivas, vi povas eldoni, sed vi heredas problemon pri registrado de revokoj. Notu tion en la ŝanĝprotokolo, ĉar la sekva revoka peto malkaŝos ĝin.

Dua kondiĉo: kiu tenas la novan privatan ŝlosilon?

Tiu decido estas sentata de la uzantoj, do faru ĝin eksplicite. Ŝlosilo generita ĉe la kliento kaj sendita kiel peto tenas la privatan duonon sur la aparato ekde la unua komando, kaj la administranto neniam tuŝas ĝin. Ŝlosilo generita ĉe la servilo estas pli facila por aparatoj sen iloj, sed ĝi faras la administranton gardanto de ĉiu klienta ŝlosilo kaj pligrandigas la efikon de servila kompromitiĝo.

Kun Easy-RSA 3 kontraŭ ekzistanta CA, importi kaj subskribi peton estas du komandoj:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Elektu la atestiltipon konscie. Peto subskribita kiel servila anstataŭ klienta atestilo donas dosieron, kiu aspektas bone kaj estas rifuzata de la kunulo, kaj la erarmesaĝo malofte diras kial. Ĉe openssl ca la sama elekto loĝas en la etendaĵoj, kiujn vi transdonas, ne en la defaŭlta sekcio.

Tria kondiĉo: ĉu la servilo bezonas pli ol atestilon?

Por ordinara OpenVPN-servilo kun atestila aŭtentikigo, la atestilo estas la registrado: la komuna nomo fariĝas la klienta identeco, kaj ĉiu klienta dosierujo, puŝita vojo aŭ statika adreso dependas de tiu nomo. Aldonu la atestilon kaj forgesu la agordon, la tunelo konektiĝas sed la bezonataj vojoj neniam aperas.

Platformoj ŝanĝas tion. OpenVPN Access Server tenas sian propran uzantan datumbazon, do subskribita atestilo ne estas konto; la konto devas ekzisti kaj esti permesita. Aliaj enirejoj mapas identecan ĉenon al grupo. Registri unu aparaton kutime tuŝas du sistemojn, kaj la atestilo estas nur la unua.

La pliiga procedo kaj kiam rekonstruo pravas

La sinsekvo, kiu aldonas aparaton sen damaĝo: konfirmu la eldonanton per fingrospuro, prenu freŝan savkopion de la PKI-dosierujo, importu kaj subskribu la peton por la klienta rolo, transdonu la atestilon kun ĝia ĉeno per la aprobita kanalo, kaj kontrolu antaŭ ol la uzanto konektiĝas:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

La cel-linio devus montri SSL client. Finu per ĝisdatigo de la CA-savkopio post la eldono, ĉar savkopio farita antaŭ la nova seria numero restarigas staton sen la ĵus aldonita aparato.

Rekonstruo pravas en tri kazoj: la CA-ŝlosilo estas kompromitita, la eldona stato estas nemaligebla perdita, aŭ vi intence ŝanĝas la ŝlosilan algoritmon aŭ la atestilan politikon. Ĉiuj tri estas projektoj kun re-registra plano por ĉiu kliento, ne paŝoj en peto por unu aparato. Se neniu validas, registru pliige.