Noile autentificări VPN eșuează deși certificatele sunt valide: verificați CRL-ul

Certificatele care mai au luni de valabilitate și autentificările care eșuează imediat indică două obiecte diferite cu două ceasuri diferite. Serverul refuză conexiunile pentru că lista certificatelor revocate pe care o consultă și-a depășit propria dată de expirare, nu pentru că certificatele utilizatorilor au devenit învechite. Reînnoirea unui certificat de utilizator nu face nimic pentru acea listă.

Separarea celor două calendare este întregul diagnostic și schimbă forma pe care trebuie să o ia remedierea.

Două ceasuri, iar doar unul dintre ele este certificatul

Un certificat poartă o fereastră de valabilitate. O listă de revocare a certificatelor poartă propria fereastră, împreună cu un emitent și o semnătură, iar verificatorii refuză să aibă încredere într-o listă al cărei moment al următoarei actualizări a trecut. Când se întâmplă asta, clientul prezintă un certificat perfect valabil, iar serverul tot închide conexiunea cu un mesaj despre listă. Utilizatorii citesc acel mesaj ca „certificatul a expirat”, ceea ce trimite cererea de reînnoire în locul greșit.

Cele două obiecte au și proprietari diferiți: certificatul vine de la CA care l-a emis, în timp ce lista este generată conform unui calendar de cel care operează acea CA. Un utilizator nu o poate reîmprospăta, iar reemiterea certificatelor nu o poate prelungi.

Citiți lista pe care serviciul o încarcă efectiv

Începeți de la configurația care rulează, nu de la fișierul pe care îl așteptați. Calea din crl-verify poate fi absolută, relativă la profil sau o copie inclusă într-o imagine, iar verificatorul citește acea copie. Inspectați-o la fața locului cu openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate și comparați datele cu ceasul serverului.

Apoi confirmați că fișierul este într-adevăr cel folosit: verificați-i semnătura cu openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, care raportează un rezultat de verificare în loc să afișeze câmpurile în tăcere. O listă semnată de altă CA, sau o copie învechită lăsată într-un al doilea director, eșuează exact ca una expirată.

Regenerați din baza de date de revocare, nu de la zero

Noua listă trebuie să provină din baza de date de revocare actuală a CA, prin procesul de semnare aprobat. Generarea unei liste goale, sau regenerarea dintr-o copie de siguranță veche a indexului, anulează în tăcere revocarea fiecărei identități adăugate după acea copie. Asta transformă o cădere a autentificării într-o regresie de securitate, și nimeni nu observă pentru că simptomul dispare.

Țineți pasul de generare sub control de versiuni împreună cu restul instrumentelor CA, astfel încât intervalul și cheia de semnare să fie documentate, nu memorate. Este suficientă o intrare în runbook care numește comanda, semnatarul și ținta de publicare. Atunci oricine este de serviciu poate regenera fără să ghicească ce fișier de index este autoritar. Stocați numărul de serie al listei și momentul următoarei actualizări împreună cu înregistrarea implementării.

Implementați acolo unde se uită verificatorul

Copiați noua listă la calea pe care o citește serviciul, setați proprietarul și modul astfel încât contul de serviciu să o poată citi, dar alții nu, și reîncărcați sau reporniți conform comportamentului documentat. Dacă daemonul memorează lista la pornire, înlocuirea fișierului fără reîncărcare nu schimbă nimic ce ar observa procesul aflat în rulare. Confirmați marcajul de timp pe care procesul îl raportează după reîncărcare.

Dacă mai multe servicii verifică clienți, implementați la fiecare dintre ele. Actualizarea unui punct final și lăsarea altuia cu copia veche produce o defecțiune care apare doar la utilizatorii care ajung pe al doilea. Păstrați o listă scurtă a acestor puncte finale în același runbook. După implementare, verificați data listei raportată de fiecare, în loc să presupuneți că copia a ajuns.

Faceți vizibil următorul termen înainte să treacă

Un interval de publicare mai lung reduce frecvența acestui incident fără a crea un proces. Alegeți intervalul din politica operatorului, apoi setați o alertă pe câmpul de următoare actualizare al listei implementate, cu suficient timp pentru regenerare și implementare. Alertați pe copia implementată, nu pe gazda CA, pentru că copia implementată este cea care eșuează.

După implementare, verificați ambele direcții: un utilizator permis se conectează, iar o identitate revocată cunoscută încă eșuează. A doua verificare este cea care prinde o regenerare incompletă și necesită o singură comandă împotriva unui profil de test pe care îl păstrați exact în acest scop.