Ce se întâmplă când înlocuiți o autoritate de certificare VPN

Înlocuirea unei autorități de certificare VPN nu este schimbarea unui fișier. În momentul în care noul CA semnează primul său certificat, fiecare validator care încă se bazează doar pe cel vechi trebuie să decidă, iar gazdele care nu primesc niciodată noua ancoră continuă să respingă parteneri buni. Am văzut cum eșuează în ambele direcții: gateway-ul a învățat noul CA, iar clienții nu, așa că noile conexiuni eșuau, în timp ce tunelurile deja ridicate rămâneau ridicate și făceau ca întreruperea să pară o problemă de rutare. Iată ce se schimbă, în ordinea în care apar defecțiunile.

O înlocuire, două schimbări separate

O autoritate de certificare este un nume, o cheie publică și cheia privată care semnează. Validatorii nu au încredere în «CA» în mod abstract. Au încredere într-un anumit certificat care se află deja într-un depozit de încredere și acceptă un emitent doar dacă un lanț de semnături ajunge la acea copie stocată. Înlocuirea CA schimbă deci două lucruri care eșuează independent: ce ancore sunt acceptate și ce identități de partener au fost emise sub ele.

Majoritatea implementărilor VPN validează în ambele direcții. Clientul autentifică certificatul gateway-ului, iar gateway-ul pe cel al clientului. O rotație care reîmprospătează doar pachetul clientului lasă serverul să respingă fiecare client care încă prezintă o identitate emisă de CA vechi, iar inversul este la fel de obișnuit. Inventariați mai întâi punctele de aplicare: depozitele de încredere ale clienților, fișierul ca al gateway-ului, orice proxy care termină TLS în fața lui și sonda care verifică punctul final din exterior.

Ce verifică un validator, în ordine

Validarea căii urcă de la certificatul partenerului prin intermediari până ajunge la o ancoră de încredere. La fiecare pas verifică semnătura, controlează că fiecare certificat este în fereastra sa de valabilitate și confirmă că restricțiile de bază și utilizarea cheii permit emitentului să semneze. Abia apoi aplicația se uită la certificatul frunză: numele alternative ale subiectului trebuie să acopere numele apelat, iar utilizarea extinsă a cheii trebuie să permită autentificarea de server sau de client.

Pentru a repeta acel parcurs offline, îndreptați -CAfile spre pachetul exact pe care îl veți implementa, nu spre depozitul sistemului. Altfel testați gazda, nu schimbarea:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Acea comandă funcționează doar împotriva unui ascultător TLS simplu, cum ar fi pagina de administrare HTTPS a gateway-ului; canalul de control al OpenVPN precede TLS, deci s_client nu poate inspecta strângerea de mână a tunelului.

Regulile de construire a căii din spatele acelor erori sunt în RFC 5280 secțiunea 6. Ele explică eșecurile care altfel par arbitrare: un intermediar expirat de care nimeni nu și-a amintit, un certificat a cărui utilizare a cheii interzice semnarea sau o restricție de nume care exclude gazda testată.

De ce tunelul vechi continuă să funcționeze

TLS și OpenVPN mențin vie o sesiune stabilită după ce strângerea de mână se termină. Nimic nu revalidează certificatul partenerului la fiecare pachet, așa că un client conectat înainte de schimbare continuă să transmită trafic până când renegociază, se reconectează sau tunelul cade. Exact acest gol face ca o înlocuire de CA să pară în regulă timp de o oră și apoi să eșueze în cel mai rău moment: un laptop se trezește din somn, o mapare NAT expiră, un gateway repornește.

Reluarea sesiunii întinde iluzia și mai mult. Un bilet de sesiune TLS îi permite clientului să revină fără a retrimite certificate, iar reluarea sare peste validarea căii pentru că prima strângere de mână a făcut-o deja. Testul onest este deci o strângere de mână completă într-un proces nou. Reporniți clientul în loc să reconectați tunelul, iar pe un profil de test luați în calcul dezactivarea biletelor, ca calea de reluare să nu poată ascunde un lanț rupt.

Țineți stratul cheii statice separat de asta. tls-auth adaugă un HMAC canalului de control, tls-crypt îl criptează și îl autentifică, iar niciunul nu transportă material de certificat, așa că rotirea oricăruia este o schimbare separată cu propriul mod de eșec. Implementările care le confundă ajung cu un client a cărui cheie statică este în regulă, al cărui certificat este depășit și al cărui mesaj de eroare nu menționează niciunul.

Capcana reutilizării numelui subiectului

Este tentant să reutilizați numele distinctiv al predecesorului ca nimic din aval să nu trebuiască schimbat. Asta menține stabilă linia emitentului în interfață și distruge singurul semnal de care aveți nevoie. Două certificate cu subiecte identice și chei diferite nu pot fi distinse după nume, așa că un pachet cu ambele ancore îi dă validatorului doi candidați și nicio regulă de alegere.

Construirea căii poate alege atunci varianta greșită, poate raporta «nu se poate obține certificatul emitentului local» deși ancora corectă este prezentă, sau poate reuși pe o gazdă și eșua pe alta cu același pachet, pentru că ordinea candidaților era diferită. Dacă numele trebuie reutilizat, țineți ambele ancore în fișiere separate în timpul tranziției și încărcați-le explicit, și fuzionați-le abia când fiecare partener prezintă noul emitent. În caz contrar, dați înlocuitorului un nume comun distinct — un sufix de generație sau de dată este suficient — ca jurnalele și textele de eroare să spună sub ce autoritate a fost emis partenerul care eșuează.

O rotație care nu dărâmă rețeaua

Pentru o înlocuire planificată, acceptați ambele ancore pentru o fereastră limitată în loc să comutați într-un singur pas. Emiteți noul CA și intermediarii săi, puneți noua ancoră în pachetul fiecărui validator lângă cea veche, și abia apoi începeți să emiteți certificate de partener din ea. Partenerii cu identități vechi se validează împotriva ancorei vechi; cei noi funcționează împotriva celei noi.

Făcut în această ordine, fiecare pas este reversibil. Eșecul pe care îl evitați este comutarea simultană, când un client care a ratat actualizarea pachetului întâlnește un gateway care a retras deja ancora veche, strângerea de mână moare și niciun jurnal nu spune care parte este depășită.

Retrageți în direcția opusă. Reemiteți fiecare identitate care trebuie să supraviețuiască, confirmați că fiecare prezintă noul lanț, apoi scoateți ancora veche din pachete. Scoateți din uz cheia privată a CA vechi, pentru că un emitent care mai poate semna înseamnă că rotația nu s-a terminat. Păstrați certificatele și evidențele de emitere pentru audit. Un emitent pierdut este restaurat la aceeași încredere; o expunere cere identități noi și nicio revenire la ancora veche.

Verificați rezultatul, nu lista de fișiere

Un fișier de încredere în directorul așteptat dovedește puțin. Aplicația poate citi altă cale, alt format sau o copie dintr-un pachet pe care o actualizare îl înlocuiește. Verificați comportamentul la ambele capete, nu existența unui fișier.

Confirmați că o conexiune nouă cu o identitate nouă reușește, apoi confirmați că o identitate emisă de CA retrasă este refuzată. Acel al doilea test este cel pe care oamenii îl sar, și singurul care arată că autoritatea veche nu mai acordă acces. Acolo unde implementarea se bazează pe CRL sau OCSP, verificați că punctele de distribuție din noile certificate se rezolvă și că partenerii care întreabă ajung la respondență.

Terminați cu un client care nu s-a conectat niciodată: ștergeți starea profilului, conectați-l și citiți lanțul negociat. Un partener care reia o sesiune din cache va raporta vesel că migrarea a funcționat, deși nu a validat nimic.