Certificatul VPN încă nu este valabil: trei cauze, o singură ordine de verificare
Încă nu este valabil înseamnă că ceasul dispozitivului rămâne în urmă, că fereastra începe într-adevăr mai târziu sau că un certificat intermediar nu s-a deschis încă. Verificați-le în această ordine.
Deschideți clientul, alegeți profilul pe care îl folosiți de luni de zile și acesta se oprește cu "certificate is not yet valid". Nimic din autentificarea dumneavoastră nu s-a schimbat, iar depozitul de încredere este probabil în regulă: certificatul prezentat la strângerea de mână are o fereastră de valabilitate care începe mai târziu decât momentul folosit de verificator. Trei situații diferite produc exact acel mesaj și necesită acțiuni diferite. Ordinea de mai jos vă spune care este cazul înainte să atingeți un ceas sau un fișier de certificat.
Care dintre cele trei cauze o vedeți
Prima cauză este locală: dispozitivul care face verificarea are un ceas anterior datei de început a certificatului. Se vede pe hardware cu o baterie CMOS moartă, pe mașini virtuale restaurate dintr-o instantanee veche, pe aparate care au fost oprite suficient de mult încât să piardă ora și în rețele unde NTP-ul de ieșire este blocat și nimeni nu a observat. Certificatul poate fi perfect valabil și totuși eșuează în acest mod.
A doua cauză aparține emitentului, pentru că certificatul chiar începe în viitor: emis devreme, generat cu o oră de început explicită sau semnat ca parte a unui pas de activare care nu a rulat încă. A treia cauză pierde cel mai mult timp, pentru că frunza este actuală în timp ce un alt certificat din lanțul prezentat nu este, așa că eroarea numește material pe care nu l-ați instalat niciodată.
O singură întrebare le separă. Eșecul urmează dispozitivul sau serviciul? Două mașini din aceeași rețea care se comportă diferit indică ceasurile. Dacă fiecare client eșuează la fel, indică fereastra certificatului și lanțul din spatele ei.
Citiți fereastra din certificatul care a fost efectiv prezentat
Nu inspectați un fișier PEM rămas de la o implementare anterioară; cereți serviciului lanțul pe care îl trimite acum. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts tipărește fiecare certificat din lanț. Salvați blocul care vă interesează și rulați openssl x509 -noout -subject -issuer -dates; ultimul tipărește notBefore și notAfter, iar aceste două valori decid. În Windows, dialogul de certificat al conexiunii și certutil -dump pe un fișier exportat arată aceleași câmpuri.
Citiți ambele capete ale ferestrei, nu doar începutul. Un certificat care se deschide peste două ore și unul care se închide peste două ore eșuează cu mesaje diferite și implică echipe diferite. Notați ce certificat numește eroarea — frunză, intermediar sau rădăcină —, pentru că asta decide dacă se poate repara ceva pe partea clientului.
Puteți testa fereastra și fără să o așteptați. Verificarea acceptă o oră explicită: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem evaluează lanțul la acel moment. Rulați-l cu ora curentă pentru a reproduce eșecul, apoi cu ora de început a certificatului pentru a confirma că același lanț trece odată ce fereastra se deschide. RFC 5280 definește câmpul de valabilitate și regula că un certificat nu trebuie folosit în afara lui, iar aceasta este exact regula pe care clientul dumneavoastră tocmai a aplicat-o.
Ceasul dumneavoastră sau al lor
Comparați ceasul dispozitivului cu începutul certificatului în UTC, dintr-o sursă în care aveți încredere. date -u dă momentul, iar timedatectl status pe un host systemd raportează și dacă ceasul este sincronizat. În Windows, w32tm /query /status arată sursa curentă și ultima sincronizare reușită. Fusul orar afișat în tavă este o alegere de afișare, nu un ceas greșit; verificatorul compară momente UTC.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
Dacă ceasul rămâne în urmă, resincronizați și retestați înainte de a schimba orice material de certificat. Un dispozitiv care este cu minute sau ore în urmă respinge fiecare certificat emis recent pe care îl întâlnește, nu doar un serviciu, așa că o explicație cu un singur serviciu este de obicei cea greșită. Dacă ceasul este corect și sincronizat, nu mai priviți dispozitivul: fereastra aparține emitentului și nicio setare locală nu trebuie ajustată ca să o treacă.
Acest tabel este întreaga decizie. Mutarea ceasului la ce așteaptă certificatul nu este o reparație, iar dezactivarea verificărilor de timp nici nu este, pentru că ambele ascund condiția care a produs eroarea.
De ce lanțul eșuează în timp ce frunza pare în regulă
Frunzele reînnoite și intermediarele de înlocuire sunt de obicei livrate împreună și nu ajung întotdeauna în același moment. Un serviciu poate trimite o frunză nouă semnată de un intermediar a cărui fereastră începe mai târziu sau poate continua să servească un intermediar mai vechi sub o frunză nouă. În ambele cazuri lanțul eșuează în timp ce datele frunzei înseși par rezonabile.
Punctele terminale cu echilibrare a încărcării transformă asta din stricat în inconsistent. Dacă o reîncercare reușește, sau o rețea funcționează iar alta nu, notați ce partener a răspuns și ce lanț a trimis înainte de a schimba setările. openssl s_client tipărește adresa conectată, așa că câteva încercări dezvăluie dacă fiecare nod servește același lanț.
Căi de reparație care păstrează verificarea intactă
O problemă de ceas se corectează pe dispozitiv cu verificarea lăsată activă. O problemă de certificat este corectată de operator cu material emis pentru o fereastră care include deja acum. Nicio setare a clientului nu face valabil un certificat încă nevalid; fanioanele care sar peste verificările de timp există ca să confirme un diagnostic, nu ca să fie implementate.
Când certificatul este pregătit pentru o activare planificată, urmați planul de tranziție. Instalați-l când se deschide fereastra lui sau folosiți procedura de suprapunere documentată de furnizor, în loc să îl instalați devreme și să învățați utilizatorii să dea clic prin avertismente. Avertismentele pe care oamenii învață să le ignore costă mai mult decât o scurtă întârziere.
În final, retestați așa cum a apărut eșecul: o sesiune nouă, același client, resursa de care aveți nevoie cu adevărat. Bibliotecile TLS pot păstra în cache un lanț verificat pentru întreaga durată de viață a unei conexiuni, iar o sesiune reluată nu îl verifică neapărat din nou, așa că o sesiune veche poate continua să eșueze după corectare sau să funcționeze în continuare după o regresie. Un fișier care se deschide într-un vizualizator dovedește doar că fișierul este lizibil; o strângere de mână finalizată dovedește că lanțul se validează.
Înainte de a închide tichetul, confirmați patru lucruri: ora UTC și starea de sincronizare a dispozitivului care eșuează, notBefore și notAfter pentru fiecare certificat din lanțul prezentat, același lanț de la un al doilea client și numele pe care eroarea îl dă certificatului. Dacă ceasul este corect și fereastra nu s-a deschis, restul este munca operatorului, iar mișcarea corectă din partea dumneavoastră este să așteptați fereastra în loc să slăbiți verificarea.