Malvalidigita VPN-atestilo ankoraŭ konektiĝas? Kontrolu CRL-plenumigon

Vi malvalidigis la atestilon, generis novan liston, kaj la malnova profilo ankoraŭ starigas tunelon. Nenio difektas en la malvalidigo mem: CRL estas subskribita deklaro, ke seria numero ne plu validas, kaj ĝi ŝanĝas aliron nur kiam la komponanto, kiu finas TLS, ŝargas ĝin, por la ĝusta eldoninto, antaŭ ol ĝi faras la akceptan decidon. Ĝuste tie kuŝas la plej multaj el tiuj kazoj, kaj tial malvalidigo kaj rifuzo estas du apartaj faktoj.

Trairu la kvin kontrolojn sube laŭ ordo, kaj haltu ĉe la unua, kiu ne validas, ĉar ĉiu posta kontrolo supozas, ke la antaŭaj veras.

Kontrolu, kiu komponanto faras la akceptan decidon

Nomu la procezon, kiu validigas la klientan atestilon, ĉar nur tiu procezo povas plenumi liston. Ĉe OpenVPN-servilo ĝi estas la demono mem, agordita per crl-verify. Ĉe ocserv ĝi estas la linio crl en ocserv.conf. Ĉe strongSwan la enigoj estas la ŝargitaj CRL-oj kune kun strictcrlpolicy. TLS-finanta prokuraĵo aŭ aparato antaŭ la VPN povas esti la reala kontrolanto, kaj se ĝi estas, la demono malantaŭ ĝi neniam vidas la klientan atestilon.

WireGuard apartenas al alia kategorio. Ĝi havas neniujn atestilojn kaj neniun malvalidigan liston; partnero estas allasata per sia publika ŝlosilo en la agordo, do finigi aliron signifas forigi tiun ŝlosilon. Se vi serĉas CRL en instalado kun nur WireGuard, tiu mekanismo ne ekzistas.

Atentu ankaŭ la kaptilon ĉe la klienta flanko. Kliento, kiu rifuzas konektiĝi ĉar ĝi ne ŝatas la servilan atestilon, plenumas la ĉenon de la servilo, ne malvalidigas sian propran identigilon. Uzanta atestilo estas malvalidigata nur tie, kie tiu uzanta atestilo estas validigata, kaj tio preskaŭ ĉiam estas la servila flanko.

Kontrolu, por kiu eldoninto la listo estis subskribita

CRL estas limigita al unu eldonanta CA. Kun radiko kaj meza CA, la foliaj atestiloj venas de la meza CA, do la listo, kiu gravas, estas la CRL de la meza CA; la listo de la radiko diras nenion pri tiuj folioj. Kontrolanto direktita al la malĝusta dosiero analizas ĝin ĝoje, trovas neniun kongruan eron kaj akceptas ĉion.

Konfirmu la parigon antaŭ ol tuŝi la demonon. La eldoninto sur la atestilo devas kongrui kun la subject de la listo:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Kiam ambaŭ venas de la sama CA, la seria numero presita por la atestilo estas la valoro, kiu devas aperi en la listo. Se ili malkongruas, vi tenas la malĝustan CRL aŭ la malĝustan kopion de ĝi.

Valideco apartenas al la sama kontrolo. nextUpdate en la pasinteco igas la liston malnova, kaj kontrolanto, kiu malsukcesas fermite, tiam rifuzos ĉiun klienton anstataŭ nur la malvalidigitan.

Kontrolu, ke la seria numero estas en la kopio, kiun la demono ŝargis

Malvalidigo skribas eron en la CA-datumbazon, kaj regenerado skribas novan dosieron. Neniu el la du agoj atingas rulantan demonon, kiu ŝargis la malnovan kopion ĉe starto. Elŝutu la liston kaj serĉu la serian numeron:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Poste kontrolu, kiel via efektivigo prenas la dosieron. OpenVPN legas vojon donitan al crl-verify unufoje ĉe starto, do nova listo bezonas restarigon aŭ restarigan signalon; la sama opcio direktita al dosierujo estas relegata por ĉiu konekto, kaj tial ekzistas la dosieruja reĝimo. strongSwan devas reŝargi siajn akreditilojn, ekzemple per swanctl --load-creds. Ke la dosiero sur la disko estas ĝusta kaj ke la kontrolanto uzas ĝin estas du malsamaj faktoj.

Kontrolu la politikon por mankanta aŭ eksdata listo

Tio estas la decido, kiun multaj instaladoj neniam faras eksplicite, kaj ĝi decidas, ĉu malvalidigo vin protektas aŭ ŝlosas ĉiujn ekstere. Fail-closed signifas, ke neniu uzebla malvalidiga informo produktas rifuzon; fail-open signifas, ke la kontrolanto daŭrigas sen ĝi. strongSwan elmetas la elekton kiel strictcrlpolicy. OpenVPN kun crl-verify rifuzas starti kun dosiero, kiun ĝi ne povas legi aŭ analizi, kaj eksdata listo aperas kiel TLS-kontrola eraro pri eksdata CRL anstataŭ kiel silenta akcepto.

Kiun ajn direkton vi elektas, la aŭtomatigo gravas pli ol la elekto: laboro, kiu regeneras la CRL antaŭ nextUpdate, kaj averto, kiam la dislokita kopio maljuniĝas, gardas ambaŭ politikojn kontraŭ tio, ke ili fariĝu incidento. Enreta kontrolado per OCSP movas la freŝecon al respondanto, sed la sama regulo validas, ĉar kontrolanto, kiu ne estas agordita por kontroli la respondon, ŝanĝas nenion.

Kontrolu la vivan seancon, poste la kopiojn de la ŝlosilo

Malvalidigo estas taksata dum atestila validigado, kiu okazas ĉe konekto kaj ĉe rekontraktado. Etablita seanco daŭras ĝis ĝi rekontraktas, kaj la defaŭlto de OpenVPN estas unufoje en horo per reneg-sec 3600. Se la persono devas esti for de la reto nun, finigu la seancon samkiel publikigi la liston, kaj poste konfirmu, ke la rekonekto estas rifuzata.

Apartigu la identigilon de ĝiaj kopioj. Forigi profilon sur unu tekkomputilo ne malhelpas alian kopion de la sama privata ŝlosilo aŭtentigi sin; malvalidigo estas tio, kio igas ĉiun kopion senutila, kaj nur post kiam la antaŭaj kontroloj validas. Donu al anstataŭa aparato propran atestilon, por ke oni povu malvalidigi unu sen tuŝi la alian.

Antaŭ ol nomi ĝin finita: la validiganta komponanto estas identigita, la eldoninto de la listo kongruas kun la eldoninto de la folio, la malvalidigita seria numero sidas en la kopio, kiun la demono efektive ŝargis, la politiko por mankantaj aŭ eksdataj listoj estas intenca kaj monitorita, kaj la aktiva seanco estis finita anstataŭ atendo. La formatoj malantaŭ ĉio ĉi estas specifitaj en RFC 5280.