La eksvalidiĝa alarmo ekas, la tunelo ankoraŭ pasas trafikon, kaj neniu konsentas ĉu la dato gravas. Ĝi gravas, sed ne ĉiam en la momento presita sur la atestilo. Eksvalidiĝinta atestilo haltigas novajn aŭtentigojn, kaj ĝi haltigas la revalidigojn, kiujn iuj efektivigoj faras ene de longdaŭra sesio. Ĉu via ekzistanta tunelo mortos noktomeze dependas de la protokolo, la kliento kaj la reagordaj agordoj de la servilo. Planu la renovigon antaŭ la dato kaj kontrolu ĝin per nova saluto anstataŭ per la sesio jam malfermita.

Trovu, kiu atestilo efektive eksvalidiĝas

Disigado enhavas servilan folian atestilon, klientajn akreditaĵojn, unu aŭ plurajn mezajn atestilojn kaj fidan ankron, kaj ili ne eksvalidiĝas kune. Legu la atestilon nomitan en la eraro kaj la ĉenon kun kiu ĝi estis prezentita, ne la unuan dosieron en la profila dosierujo. Servila folia atestilo, kiu renoviĝas pure, tamen povas malsukcesi se la meza atestilo super ĝi eksvalidiĝis. Notu subjekton, eldonanton, not-after kaj la disigan lokon de ĉiu dosiero antaŭ ol ŝanĝi ion.

La fida ankro kutime estas la plej longviva objekto kaj la malplej verŝajna kaŭzo.

Kial viva sesio povas postvivi la daton

Aŭtentigo okazas ĉe konekta starigo, kaj iuj protokoloj rekontrolas identecon poste. OpenVPN reagordas la datkanalon laŭ tempigilo, do reagordo prezentanta eksvalidiĝintan atestilon malsukcesas eĉ kvankam la tunelo funkcias de horoj. Efektivigoj, kiuj neniam revalidigas, povas porti starigitan sesion preter la eksvalidiĝa dato, kaj tial «ĝi ankoraŭ funkcias» ne estas pruvo. Nek unu el la du kondutoj estas io, pri kio oni povas plani.

Traktu la daton kiel la limdaton por novaj salutoj, kaj la sesian vivdaŭron kiel pruntitan tempon.

Kontrolu la horloĝon antaŭ ol kulpigi la atestilon

Valideco estas taksata laŭ la loka horloĝo, do aparato kun malĝusta tempo raportas validecan malsukceson por atestilo tute aktuala. Kontrolu la klienton, la servilon kaj ajnan aparaton en la vojo.

Horloĝo, kiu restarigas ĉe lanĉo, klarigas paneojn aperantajn nur post elektra interrompo.

Renovigu per la aŭtoritato, kiu eldonis ĝin

Konservu la identecon, la celatan uzon kaj kongruan ŝlosilagordon. Se la renovigo enkondukas novan eldonanton aŭ fiksitan atestilon, klientoj bezonas kunordigitan fidan ĝisdatigon anstataŭ servila dosiera anstataŭigo. Protektu privatajn ŝlosilojn dum eldono kaj disdonado, ĉar renovigita atestilo ne revokas kompromititan malnovan ŝlosilon. Pasvorta restarigo ne estas renovigo, kion ajn la bileto diras.

Publikigu la novan ĉenon plene, ĉar folio sen sia meza atestilo estas duona renovigo funkcianta nur sur maŝinoj, kiuj jam kaŝmemorigis ĝin.

Pruvu ĝin per nova saluto, tenu rereiron

Post disigado, starigu novan permesitan konekton de reprezenta kliento kaj provu la efektivan aplikaĵon. Kontrolu, ke la ĉeno liveriĝas kiel klientoj atendas kaj ke ajna revoka informo atingeblas. Tenu rereiron, kiu ne dependas de fido al eksvalidiĝinta materialo, por ke vi povu reveni al la antaŭa stato sen malfortigi la kontroladon. Forigu la malnovajn dosierojn nur post kiam la anstataŭigo estas kontrolita.

Ekzistantaj sesioj eble ankoraŭ spegulas pli fruan staton, do ili pruvas nenion en ajna direkto.

La ordo, kiun mi uzas tiun tagon

Konfirmu la eksvalidiĝantan objekton kaj ĝian ĉenon, poste konfirmu la horloĝojn:

  • Kiu atestilo eksvalidiĝas, kaj al kiu ĉeno ĝi apartenas.
  • Ĉu ĉiu meza atestilo estas disigita kaj publikigita.
  • Klientaj kaj servilaj horloĝoj kongruas ene de racia marĝeno.
  • Nova saluto sukcesas de reprezenta kliento.
  • Revoka informo atingeblas.
  • Ekzistas rereiro, kiu ne malfortigas la kontroladon.

Poste renovigu, disigu la plenan ĉenon, testu per nova saluto kaj nur poste purigu. Validperiodoj kaj la reguloj por taksi ilin estas difinitaj en RFC 5280, kaj la dato ne estas surprizo se via observado rigardis la objekton, kiu efektive eksvalidiĝas.

Rilataj artikoloj