Alerta de expirare se declanșează, tunelul încă trece trafic, iar nimeni nu este de acord dacă data contează. Contează, dar nu întotdeauna în momentul imprimat pe certificat. Un certificat expirat oprește autentificările noi și oprește revalidările pe care unele implementări le fac în interiorul unei sesiuni de lungă durată. Dacă tunelul tău existent moare la miezul nopții depinde de protocol, de client și de setările de renegociere ale serverului. Planifică reînnoirea înainte de dată și verific-o cu o autentificare nouă, nu cu sesiunea care era deja deschisă.

Află care certificat expiră de fapt

O implementare conține un certificat frunză de server, acreditări de client, unul sau mai multe intermediare și o ancoră de încredere, iar acestea nu expiră împreună. Citește certificatul numit în eroare și lanțul cu care a fost prezentat, nu primul fișier din directorul profilului. Un frunză de server care se reînnoiește curat poate eșua totuși dacă intermediarul de deasupra a expirat. Notează subiectul, emitentul, not-after și locația de implementare a fiecărui fișier înainte de a schimba ceva.

Ancora de încredere este de obicei obiectul cu cea mai lungă viață și cauza cea mai puțin probabilă.

De ce o sesiune activă poate supraviețui datei

Autentificarea are loc la stabilirea conexiunii, iar unele protocoale reverifică identitatea mai târziu. OpenVPN renegociază canalul de date pe un temporizator, așa că o renegociere care prezintă un certificat expirat eșuează chiar dacă tunelul funcționează de ore. Implementările care nu revalidează niciodată pot duce o sesiune stabilită dincolo de data expirării, și de aceea «încă funcționează» nu este o dovadă. Niciuna dintre cele două comportamente nu este ceva pe care să poți planifica.

Tratează data ca termenul pentru autentificările noi, iar durata sesiunii ca timp împrumutat.

Verifică ceasul înainte de a da vina pe certificat

Valabilitatea este evaluată față de ceasul local, așa că un dispozitiv cu ora greșită raportează o eroare de valabilitate pentru un certificat perfect actual. Verifică clientul, serverul și orice echipament de pe traseu.

Un ceas care se resetează la pornire explică defecțiunile care apar doar după o pană de curent.

Reînnoiește prin autoritatea care l-a emis

Păstrează identitatea, scopul prevăzut și o configurație de cheie compatibilă. Dacă reînnoirea introduce un emitent nou sau un certificat fixat, clienții au nevoie de o actualizare coordonată a încrederii, nu de o înlocuire de fișier pe server. Protejează cheile private în timpul emiterii și distribuției, pentru că un certificat reînnoit nu revocă o cheie veche compromisă. Resetarea parolei nu este o reînnoire, orice ar spune tichetul.

Publică noul lanț în întregime, pentru că un frunză fără intermediarul său este o jumătate de reînnoire care funcționează doar pe mașinile care l-au stocat deja în cache.

Dovedește-o cu o autentificare nouă, păstrează o revenire

După implementare, stabilește o conexiune permisă nouă de la un client reprezentativ și testează aplicația reală. Verifică dacă lanțul este livrat așa cum se așteaptă clienții și dacă orice informație de revocare este accesibilă. Păstrează o revenire care nu depinde de încrederea în material expirat, ca să poți reveni la starea anterioară fără a slăbi verificarea. Elimină fișierele vechi doar după ce înlocuitorul este verificat.

Sesiunile existente pot reflecta încă o stare anterioară, așa că nu dovedesc nimic în niciun sens.

Ordinea pe care o folosesc în ziua respectivă

Confirmă obiectul care expiră și lanțul lui, apoi confirmă ceasurile:

  • Ce certificat expiră și cărui lanț aparține.
  • Dacă fiecare intermediar este implementat și publicat.
  • Ceasurile clientului și serverului coincid într-o marjă rezonabilă.
  • O autentificare nouă reușește de la un client reprezentativ.
  • Informația de revocare este accesibilă.
  • Există o revenire care nu slăbește verificarea.

Apoi reînnoiește, implementează lanțul complet, testează cu o autentificare nouă și abia după aceea curăță. Perioadele de valabilitate și regulile de evaluare a acestora sunt definite în RFC 5280, iar data nu este o surpriză dacă monitorizarea ta urmărea obiectul care expiră cu adevărat.

Articole similare