Kio okazas, kiam vi anstataŭigas VPN-an atestgardanton

Anstataŭigi VPN-an atestgardanton ne estas simpla dosiera anstataŭigo. En la momento, kiam la nova CA subskribas sian unuan atestilon, ĉiu validigilo, kiu ankoraŭ fidas nur la malnovan, devas decidi, kaj gastigantoj, kiuj neniam ricevas la novan ankron, daŭre rifuzas bonajn partnerojn. Mi vidis ĝin fiaski ambaŭdirekte: la enirejo lernis la novan CA kaj la klientoj ne, do novaj ligoj malsukcesis, dum tuneloj jam starantaj restis starantaj kaj igis la interrompon aspekti kiel enkursiga problemo. Jen kio ŝanĝiĝas, laŭ la ordo, en kiu aperas fiaskoj.

Unu anstataŭigo, du apartaj ŝanĝoj

Atestgardanto estas nomo, publika ŝlosilo kaj la privata ŝlosilo, kiu subskribas. Validigiloj neniam fidas «la CA» en abstrakto. Ili fidas unu specifan atestilon, kiu jam kuŝas en fido-konservejo, kaj ili akceptas eldonanton nur se subskriba ĉeno atingas tiun konservitan kopion. La anstataŭigo de la CA do ŝanĝas du aferojn, kiuj fiaskas sendepende: kiuj ankroj estas akceptataj, kaj kiuj partneraj identecoj estis eldonitaj sub ili.

Plej multaj VPN-aj instaloj validigas ambaŭdirekte. La kliento aŭtentikigas la atestilon de la enirejo, kaj la enirejo aŭtentikigas la atestilon de la kliento. Ŝanĝo, kiu nur refreŝigas la klientan pakaĵon, lasas la servilon rifuzi ĉiun klienton, kiu ankoraŭ prezentas identecon de la malnova CA, kaj la malo estas same ofta. Unue listigu la devigajn punktojn: klientaj fido-konservejoj, la ca dosiero de la enirejo, iu ajn TLS-finanta prokura servilo antaŭ ĝi, kaj la kontrolo, kiu testas la finpunkton de ekstere.

Kion kontrolas validigilo, laŭ ordo

Voja validigado supreniras de la partnera atestilo tra eventualaj interuloj ĝis ĝi atingas fidata ankron. Ĉe ĉiu paŝo ĝi kontrolas la subskribon, certigas, ke ĉiu atestilo estas ene de sia valideca fenestro, kaj konfirmas, ke bazaj limigoj kaj ŝlosila uzo permesas al la eldonanto subskribi. Nur poste la aplikaĵo rigardas la finan atestilon: la subjektaj alternativaj nomoj devas kovri la vokitan nomon, kaj la etendita ŝlosila uzo devas permesi servilan aŭ klientan aŭtentikigon.

Por ripeti tiun iradon eksterrete, direktu -CAfile al la ĝusta pakaĵo, kiun vi instalos, ne al la sistema konservejo. Alikaze vi testas la gastiganton, ne la ŝanĝon:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Tiu komando funkcias nur kontraŭ ordinara TLS-auskultanto, kiel la HTTPS-administra paĝo de la enirejo; la regada kanalo de OpenVPN antaŭas TLS, do s_client ne povas inspekti la manpremon de la tunelo.

La vojo-konstruaj reguloj malantaŭ tiuj eraroj troviĝas en RFC 5280 sekcio 6. Ili klarigas la fiaskojn, kiuj alikaze aspektas arbitraj: eksvalida interulo, kiun neniu memoris, atestilo, kies ŝlosila uzo malpermesas subskribadon, aŭ nomlimigo, kiu ekskludas la gastiganton, kiun vi testas.

Kial la malnova tunelo daŭre funkcias

TLS kaj OpenVPN ambaŭ tenas starigitan sesion viva post la fino de la manpremo. Nenio revalidigas la partneran atestilon po pakaĵo, do kliento, kiu ligiĝis antaŭ la ŝanĝo, daŭre pasigas trafikon ĝis ĝi reinterkonsentos, relikiĝos aŭ la tunelo falos. Ĝuste tiu breĉo igas, ke CA-anstataŭigo povas aspekti bona dum horo kaj poste fiaski en la plej malbona momento: tekkomputilo vekiĝas el dormo, NAT-mapado eksvalidiĝas, enirejo restartiĝas.

Sesio-rekomenco plilongigas la iluzion pli. TLS-sesia bileto permesas al kliento reveni sen resendi atestilojn, kaj rekomenco preterlasas vojan validigadon, ĉar la unua manpremo jam faris ĝin. Do la honesta testo estas plena manpremo en nova procezo. Restartigu la klienton anstataŭ religigi la tunelon, kaj ĉe testa profilo konsideru malŝalti biletojn, por ke la rekomenca vojo ne povu kaŝi rompitan ĉenon.

Tenu la statikŝlosilan tavolon aparte de ĉi tio. tls-auth aldonas HMAC al la regada kanalo, tls-crypt ĝin ĉifras kaj aŭtentikigas, kaj neniu el ili portas atestilan materialon, do rotacio de iu ajn el ili estas aparta ŝanĝo kun sia propra fiaskmaniero. Instaloj, kiuj miksas la du, finiĝas kun kliento, kies statika ŝlosilo estas bona, kies atestilo estas eksdata kaj kies erarmesaĝo mencias nek unu nek la alian.

La kaptilo de reuzado de la subjekta nomo

Logas reuzi la distingan nomon de la antaŭulo, por ke nenio malsupre devu ŝanĝiĝi. Tio tenas la eldonantan linion stabila en la fasado kaj detruas la solan signalon, kiun vi bezonas. Du atestiloj kun identaj subjektoj kaj malsamaj ŝlosiloj ne distingeblas laŭ nomo, do pakaĵo enhavanta ambaŭ ankrojn donas al la validigilo du kandidatojn kaj neniun regulon por elekti.

Voja konstruado tiam povas elekti la malĝustan, raporti «ne eblas akiri lokan eldonantan atestilon» dum la ĝusta ankro ĉeestas, aŭ sukcesi ĉe unu gastiganto kaj fiaski ĉe alia kun la sama pakaĵo, ĉar la kandidata ordo diferencis. Se la nomo devas esti reuzata, tenu ambaŭ ankrojn en apartaj dosieroj dum la transiro kaj ŝargu ilin eksplicite, kaj kunfandu ilin nur kiam ĉiu partnero prezentas la novan eldonanton. Alie donu al la anstataŭigo apartan komunan nomon — sufikso de generacio aŭ dato sufiĉas — por ke protokoloj kaj erartekstoj diru, sub kiu aŭtoritato estis eldonita la fiaskanta partnero.

Transiro, kiu ne faligas la reton

Por planita anstataŭigo, akceptu ambaŭ ankrojn dum limigita periodo anstataŭ ŝalti unupaŝe. Eldonu la novan CA kaj ĝiajn interulojn, metu la novan ankron en la pakaĵon de ĉiu validigilo apud la malnova, kaj nur poste komencu eldoni partnerajn atestilojn el ĝi. Partneroj kun malnovaj identecoj validiĝas kontraŭ la malnova ankro; novaj funkcias kontraŭ la nova.

Farite en tiu ordo, ĉiu paŝo estas malfarebla. La fiasko, kiun vi evitas, estas la samtempa ŝalto, kie kliento, kiu maltrafis la pakaĵan ĝisdatigon, renkontas enirejon, kiu jam retiriĝis la malnovan ankron, la manpremo mortas, kaj neniu protokolo diras, kiu flanko estas eksdata.

Retiriĝu en la kontraŭan direkton. Reeldonu ĉiun identecon, kiu devas pluvivi, konfirmu, ke ĉiu prezentas la novan ĉenon, kaj poste forigu la malnovan ankron el la pakaĵoj. Retirigu la privatan ŝlosilon de la malnova CA el servo, ĉar eldonanto, kiu ankoraŭ povas subskribi, signifas, ke la transiro ne finiĝis. Konservu la atestilojn kaj eldonajn registrojn por revizio. Perdita eldonanto estas restarigata al la sama fido; malkaŝiĝo postulas novajn identecojn kaj neniun revenon al la malnova ankro.

Kontrolu la rezulton, ne la dosierliston

Fida dosiero en la atendita dosierujo pruvas malmulte. La aplikaĵo povas legi alian vojon, alian formaton aŭ kopion ene de pakaĵo, kiun ĝisdatigo anstataŭigas. Kontrolu konduton ĉe ambaŭ finoj, ne ĉu dosiero ekzistas.

Konfirmu, ke freŝa ligo kun nova identeco sukcesas, poste konfirmu, ke identeco eldonita de la retiriĝinta CA estas rifuzata. Tiu dua testo estas tiu, kiun homoj preterlasas, kaj la sola, kiu montras, ke la malnova aŭtoritato ne plu donas aliron. Kie la instalo dependas de CRL aŭ OCSP, kontrolu, ke la distribuaj punktoj en la novaj atestiloj solviĝas kaj ke la respondanto atingeblas de la partneroj, kiuj demandas ĝin.

Finu per kliento, kiu neniam ligiĝis: viŝu la staton de ĝia profilo, ligiĝu kaj legu la interkonsentitan ĉenon. Partnero rekomencanta kaŝmemorigitan sesion ĝoje raportos, ke la migrado sukcesis, dum ĝi validigis nenion.