Ai revocat certificatul, ai generat o listă nouă, iar profilul vechi tot ridică un tunel. Revocarea în sine nu e stricată: un CRL este o declarație semnată că un număr de serie nu mai este valid, și schimbă accesul doar când componenta care închide TLS îl încarcă, pentru emitentul corect, înainte de a lua decizia de acceptare. Aici se află majoritatea acestor cazuri, și de aceea revocarea și refuzul sunt două fapte distincte.

Parcurge cele cinci verificări de mai jos în ordine și oprește-te la prima care nu se susține, pentru că fiecare verificare ulterioară le presupune adevărate pe cele anterioare.

Verifică ce componentă ia decizia de acceptare

Numește procesul care validează certificatul clientului, pentru că doar acel proces poate aplica o listă. Pe un server OpenVPN este daemonul însuși, configurat cu crl-verify. Pe ocserv este linia crl din ocserv.conf. Pe strongSwan intrările sunt CRL-urile încărcate împreună cu strictcrlpolicy. Un proxy sau un echipament care închide TLS în fața VPN-ului poate fi verificatorul real, iar dacă este, daemonul din spate nu vede niciodată certificatul clientului.

WireGuard aparține altei categorii. Nu are certificate și nici listă de revocare; un peer este admis prin cheia sa publică din configurație, așa că închiderea accesului înseamnă eliminarea acelei chei. Dacă cauți un CRL într-un deployment doar cu WireGuard, acel mecanism nu există.

Fii atent și la capcana din partea clientului. Un client care refuză să se conecteze pentru că nu-i place certificatul serverului aplică lanțul serverului, nu își revocă propria credențială. Un certificat de utilizator este revocat doar acolo unde acel certificat de utilizator este validat, și acesta este aproape întotdeauna partea serverului.

Verifică pentru ce emitent a fost semnată lista

Un CRL este limitat la o singură CA emitentă. Cu o rădăcină și o intermediară, certificatele frunză vin de la intermediară, deci lista care contează este CRL-ul intermediarei; lista rădăcinii nu spune nimic despre acele frunze. Un verificator îndreptat spre fișierul greșit îl parsează voios, nu găsește nicio intrare potrivită și acceptă tot.

Confirmă împerecherea înainte de a atinge daemonul. Emitentul de pe certificat trebuie să corespundă cu subjectul listei:

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

Când ambele vin de la aceeași CA, numărul de serie imprimat pentru certificat este valoarea care trebuie să apară în listă. Dacă nu coincid, ai CRL-ul greșit sau copia greșită a acestuia.

Valabilitatea ține de aceeași verificare. Un nextUpdate în trecut face lista învechită, iar un verificator care eșuează închis va respinge atunci fiecare client în loc de doar cel revocat.

Verifică dacă numărul de serie se află în copia încărcată de daemon

Revocarea scrie o intrare în baza de date a CA, iar regenerarea scrie un fișier nou. Niciuna dintre acțiuni nu ajunge la un daemon în execuție care a încărcat copia veche la pornire. Descarcă lista și caută numărul de serie:

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

Apoi verifică modul în care implementarea ta preia fișierul. OpenVPN citește o cale dată lui crl-verify o singură dată la pornire, deci o listă nouă necesită o repornire sau un semnal de repornire; aceeași opțiune îndreptată spre un director este recitită la fiecare conexiune, și de aceea există modul director. strongSwan trebuie să-și reîncarce credențialele, de exemplu cu swanctl --load-creds. Faptul că fișierul de pe disc este corect și faptul că verificatorul îl folosește sunt două lucruri diferite.

Verifică politica pentru o listă lipsă sau expirată

Aceasta este decizia pe care multe implementări nu o iau niciodată explicit, și ea hotărăște dacă revocarea te protejează sau încuie pe toată lumea afară. Fail-closed înseamnă că nicio informație de revocare utilizabilă nu produce o respingere; fail-open înseamnă că verificatorul merge mai departe fără ea. strongSwan expune alegerea ca strictcrlpolicy. OpenVPN cu crl-verify refuză să pornească pe un fișier pe care nu îl poate citi sau parsa, iar o listă expirată apare ca o eroare de verificare TLS despre un CRL expirat în loc de o acceptare silențioasă.

State of the revocation dataFail-closed resultFail-open result
List missing or unreadableVerification fails, so expect an outageEvery client connects, including the revoked one
List past nextUpdateValidation errors until a fresh list is deployedOld status is trusted indefinitely
Revoked serial present in the loaded listHandshake rejected for that certificateHandshake rejected for that certificate

Orice direcție ai alege, automatizarea contează mai mult decât alegerea: un job care regenerează CRL-ul înainte de nextUpdate și o alertă când copia implementată îmbătrânește împiedică ambele politici să devină un incident. Verificarea online cu OCSP mută prospețimea la un responder, dar se aplică aceeași regulă, pentru că un verificator neconfigurat să verifice răspunsul nu schimbă nimic.

Verifică sesiunea activă, apoi copiile cheii

Revocarea este evaluată în timpul validării certificatului, care are loc la conectare și la renegociere. O sesiune stabilită continuă până când renegociază, iar valoarea implicită a OpenVPN este o dată pe oră cu reneg-sec 3600. Dacă persoana trebuie să fie acum în afara rețelei, termină sesiunea pe lângă publicarea listei, apoi confirmă că reconectarea este refuzată.

Separă credențiala de copiile ei. Ștergerea unui profil de pe un laptop nu împiedică o altă copie a aceleiași chei private să se autentifice; revocarea este ce face fiecare copie inutilă, și doar când verificările anterioare se susțin. Oferă unui dispozitiv de schimb propriul certificat, ca unul să poată fi revocat fără a-l atinge pe celălalt.

Înainte de a-l numi încheiat: componenta care validează este identificată, emitentul listei corespunde emitentului frunzei, numărul de serie revocat se află în copia pe care daemonul a încărcat-o efectiv, politica pentru listele lipsă sau expirate este deliberată și monitorizată, iar sesiunea activă a fost terminată în loc să fie așteptată. Formatele din spatele tuturor acestora sunt specificate în RFC 5280.

Articole similare