Novaj VPN-ensalutoj malsukcesas dum la atestiloj validas: kontrolu la CRL

Atestiloj kun monatoj restantaj kaj ensalutoj, kiuj tuj malsukcesas, montras al du malsamaj objektoj kun du malsamaj horloĝoj. La servilo rifuzas konektojn ĉar la listo de revokitaj atestiloj, kiun ĝi konsultas, preterpasis sian propran limdaton, ne ĉar la atestiloj de la uzantoj malaktualiĝis. Renovigi uzantan atestilon faras nenion por tiu listo.

Apartigi la du horarojn estas la tuta diagnozo, kaj ĝi ŝanĝas kia la riparo devas esti.

Du horloĝoj, kaj nur unu el ili estas la atestilo

Atestilo portas validperiodan fenestron. Revoka listo de atestiloj portas sian propran fenestron, plus eldonanton kaj subskribon, kaj kontrolantoj rifuzas fidi liston, kies tempo de sekva ĝisdatigo pasis. Kiam tio okazas, la kliento prezentas tute validan atestilon kaj la servilo tamen faligas la konekton kun mesaĝo pri la listo. Uzantoj legas tiun mesaĝon kiel 'la atestilo eksdatiĝis', kio sendas la renovigan peton al la malĝusta loko.

La du objektoj ankaŭ havas malsamajn posedantojn: la atestilo venas de la CA, kiu eldonis ĝin, dum la listo estas generata laŭ horaro de tiu, kiu funkciigas tiun CA. Uzanto ne povas ĝin refreŝigi, kaj reeldono de atestiloj ne povas ĝin plilongigi.

Legu la liston, kiun la servo fakte ŝargas

Komencu de la kuranta agordo anstataŭ de la dosiero, kiun vi atendas. La vojo de crl-verify povas esti absoluta, relativa al la profilo, aŭ kopio bakita en bildon, kaj la kontrolanto legas tiun kopion. Inspektu ĝin surloke per openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate kaj komparu la datojn kun la horloĝo de la servilo.

Poste konfirmu, ke la dosiero vere estas la uzata: kontrolu ĝian subskribon per openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, kiu raportas kontrolrezulton anstataŭ silente presi kampojn. Listo subskribita de alia CA, aŭ eksdata kopio lasita en dua dosierujo, malsukcesas ĝuste kiel eksdata unu.

Regeneru el la revoka datumbazo, ne de nulo

La nova listo devas veni el la nuna revoka datumbazo de la CA, per la aprobita subskriba proceso. Generi malplenan liston, aŭ regeneri el malnova savkopio de la indekso, silento nuligas la revokon de ĉiu identeco aldonita post tiu savkopio. Tio ŝanĝas ensalutan interrompon en sekurecan regreson, kaj neniu rimarkas ĝin ĉar la simptomo malaperas.

Tenu la generan paŝon sub versia kontrolo kun la resto de la iloj de la CA, por ke la intervalo kaj la subskriba ŝlosilo estu dokumentitaj anstataŭ memorataj. Runlibra ero, kiu nomas la komandon, la subskribanton kaj la publikigan celon, sufiĉas. Tiam iu ajn deĵoranta povas regeneri sen diveni, kiu indeksa dosiero estas aŭtoritata. Konservu la serian numeron de la listo kaj la tempon de sekva ĝisdatigo kun la disfaldiga registro.

Disvolvu tien, kien rigardas la kontrolanto

Kopiu la novan liston al la vojo, kiun la servo legas, agordu posedanton kaj reĝimon tiel, ke la serva konto povas legi ĝin sed aliaj ne, kaj reŝargu aŭ restartigu laŭ la dokumentita konduto. Se la demono kaŝmemorigas la liston ĉe ekfunkciigo, anstataŭigi la dosieron sen reŝargo ŝanĝas nenion, kion la kuranta procezo rimarkos. Konfirmu la tempomarkon, kiun la procezo raportas post la reŝargo.

Se pluraj servoj kontrolas klientoj, disvolvu al ĉiu el ili. Ĝisdatigi unu finpunkton kaj lasi alian kun la malnova kopio produktas fiaskon, kiu aperas nur ĉe la uzantoj, kiuj surteriĝas sur la dua. Tenu mallongan liston de tiuj finpunktoj en la sama runlibro. Post la disfaldado, kontrolu la raportitan listodaton de ĉiu el ili anstataŭ supozi, ke la kopio alvenis.

Igu la sekvan limdaton videbla antaŭ ol ĝi pasas

Pli longa publikiga intervalo malaltigas la oftecon de ĉi tiu okazaĵo sen krei procezon. Elektu la intervalon laŭ la politiko de la operatoro, poste alarmu pri la kampo de sekva ĝisdatigo de la disvolvita listo kun sufiĉa antaŭtempo por regeneri kaj disvolvi. Alarmu pri la disvolvita kopio, ne pri la gastiganto de la CA, ĉar la disvolvita kopio estas tiu, kiu malsukcesas.

Post la disfaldado, kontrolu ambaŭ direktojn: permesita uzanto konektiĝas, kaj konata revokita identeco ankoraŭ malsukcesas. La dua kontrolo estas tiu, kiu kaptas nekompletan regeneradon, kaj ĝi postulas unu komandon kontraŭ testa profilo, kiun vi tenas ĝuste por ĉi tiu celo.