VPN-sertifikaat nog nie geldig nie: drie oorsake, een kontroleorde
Nog-nie-geldig beteken die toestel se klok is agter, die venster begin werklik later, of 'n tussenliggende sertifikaat het nog nie oopgegaan nie. Kontroleer hulle in daardie orde.
Jy maak die kliënt oop, kies die profiel wat jy al maande lank gebruik, en dit stop met "certificate is not yet valid". Niks aan jou aanmelding het verander nie, en die vertrouensbewaarplek is waarskynlik in orde: die sertifikaat wat in die handdruk aangebied word, dra 'n geldigheidsvenster wat later begin as die oomblik wat die verifieerder gebruik. Drie verskillende situasies lewer daardie presiese boodskap, en hulle vereis verskillende optredes. Die orde hieronder sê vir jou watter een jy het voordat jy aan 'n klok of 'n sertifikaatlêer raak.
Watter van die drie oorsake jy voor het
Die eerste oorsaak is plaaslik: die toestel wat die kontrole doen, het 'n klok wat vroeër is as die sertifikaat se begindatum. Jy sien dit op hardeware met 'n dooie CMOS-battery, op virtuele masjiene wat uit 'n ou momentopname herstel is, op toestelle wat lank genoeg afgeskakel was om tyd te verloor, en op netwerke waar uitgaande NTP geblokkeer is en niemand dit opgemerk het nie. Die sertifikaat kan heeltemal geldig wees en tog op hierdie manier misluk.
Die tweede oorsaak hoort by die uitreiker, want die sertifikaat begin werklik in die toekoms: vroeg uitgereik, gegenereer met 'n eksplisiete begintyd, of onderteken as deel van 'n aktiveringsstap wat nog nie geloop het nie. Die derde oorsaak mors die meeste tyd, want die blaar is geldig terwyl 'n ander sertifikaat in die aangebode ketting dit nie is nie, so die fout noem materiaal wat jy nooit geïnstalleer het nie.
Een vraag skei hulle. Volg die mislukking die toestel of die diens? Twee masjiene op dieselfde netwerk wat anders optree, wys op klokke. Elke kliënt wat op dieselfde manier misluk, wys op die sertifikaat se venster en die ketting daarby.
Lees die venster uit die sertifikaat wat werklik aangebied is
Moenie 'n PEM-lêer ondersoek wat uit 'n vroeëre ontplooiing oorgebly het nie; vra die diens vir die ketting wat dit nou stuur. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts druk elke sertifikaat in die ketting. Stoor die blok wat jou aangaan en voer openssl x509 -noout -subject -issuer -dates uit; die laaste een druk notBefore en notAfter, en dit is die twee waardes wat hierdie saak beslis. Op Windows wys die sertifikaatdialoog vir die verbinding en certutil -dump op 'n uitgevoerde lêer dieselfde velde.
Lees albei kante van die venster, nie net die begin nie. 'n Sertifikaat wat oor twee uur oopgaan en een wat oor twee uur sluit, misluk met verskillende boodskappe en betrek verskillende spanne. Let op watter sertifikaat die fout noem, of dit blaar, tussenliggende of wortel is, want dit bepaal of enigiets aan die kliëntkant hoegenaamd reggemaak kan word.
Jy kan die venster ook toets sonder om daarop te wag. Verifikasie aanvaar 'n eksplisiete tyd: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem evalueer die ketting teen daardie tydstempel. Voer dit met die huidige tyd uit om die mislukking te herhaal, dan met die sertifikaat se begintyd om te bevestig dat dieselfde ketting slaag sodra die venster oopgaan. RFC 5280 definieer die geldigheidsveld en die reël dat 'n sertifikaat nie buite dit gebruik mag word nie, en dit is die reël wat jou kliënt pas afgedwing het.
Jou klok, of hulle s'n
Vergelyk die toestel se klok met die sertifikaat se begin in UTC, uit 'n bron wat jy vertrou. date -u gee die oomblik, en timedatectl status op 'n systemd-gasheer rapporteer ook of die klok gesinkroniseer is. Op Windows wys w32tm /query /status die huidige bron en die laaste suksesvolle sinkronisasie. 'n Tydsone in die taakbalk is 'n vertoonkeuse, nie 'n verkeerde klok nie; die verifieerder vergelyk UTC-oomblikke.
| 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 |
As die klok agter is, hersinkroniseer en toets weer voordat jy enige sertifikaatmateriaal verander. 'n Toestel wat minute of ure verkeerd is, verwerp elke onlangs uitgereikte sertifikaat wat dit teëkom, nie net een diens nie, so 'n verklaring wat net een diens blameer, is gewoonlik verkeerd. As die klok reg en gesinkroniseer is, hou op om na die toestel te kyk: die venster hoort by die uitreiker, en geen plaaslike instelling moet aangepas word om dit te laat slaag nie.
Daardie tabel is die hele besluit. Om jou klok na wat die sertifikaat verwag te skuif, is nie 'n herstel nie, en om tydkontroles af te skakel is ook nie een nie, want albei verberg die toestand wat die fout veroorsaak het.
Waarom die ketting misluk terwyl die blaar reg lyk
Hernude blare en vervangende tussenliggende sertifikate word gewoonlik saam verskeep, en hulle land nie altyd op dieselfde oomblik nie. 'n Diens kan 'n nuwe blaar stuur wat deur 'n tussenliggende sertifikaat onderteken is waarvan die eie venster later begin, of 'n ouer tussenliggende sertifikaat onder 'n vars blaar aanhou bedien. In albei gevalle misluk die ketting terwyl die blaar se eie datums redelik lyk.
Lasverspreide eindpunte maak dit van stukkend na onbestendig. As 'n herprobeerslag slaag, of een netwerk werk terwyl 'n ander nie werk nie, teken op watter eweknie geantwoord het en watter ketting dit gestuur het voordat jy instellings verander. openssl s_client druk die gekoppelde adres, so 'n paar pogings wys of elke nodus dieselfde ketting bedien.
Herstelpaaie wat validering ongeskonde laat
'n Klokprobleem word op die toestel reggemaak met validering aan. 'n Sertifikaatprobleem word deur die operateur reggemaak met materiaal wat uitgereik is vir 'n venster wat reeds nou insluit. Geen kliëntinstelling maak 'n nog-nie-geldige sertifikaat geldig nie; die vlae wat tydkontroles oorslaan, bestaan sodat jy 'n diagnose kan bevestig, nie sodat jy hulle kan verskeep nie.
Wanneer die sertifikaat vir 'n beplande aktivering voorberei is, volg die oorskakelplan. Installeer dit wanneer sy venster oopgaan, of gebruik die oorvleuelingsprosedure wat die verskaffer dokumenteer, eerder as om vroeg te installeer en gebruikers te leer om deur waarskuwings te klik. Waarskuwings wat mense leer ignoreer, kos meer as 'n kort vertraging.
Toets laastens weer op die manier waarop die mislukking gebeur het: 'n nuwe sessie, dieselfde kliënt, die hulpbron wat jy werklik nodig het. TLS-biblioteke kan 'n geverifieerde ketting vir die leeftyd van 'n verbinding in die kas hou, en 'n hervatte sessie kontroleer dit nie noodwendig weer nie, so 'n ou sessie kan na die herstel aanhou misluk of na 'n regressie aanhou werk. 'n Lêer wat in 'n kyker oopmaak, bewys net dat die lêer leesbaar is; 'n voltooide handdruk bewys dat die ketting valideer.
Voordat jy die kaartjie sluit, bevestig vier dinge: die mislukte toestel se UTC-tyd en sinkroniseringstoestand, die notBefore en notAfter van elke sertifikaat in die aangebode ketting, dieselfde ketting van 'n tweede kliënt, en die naam wat die fout aan die sertifikaat gee. As die klok reg is en die venster nog nie oopgegaan het nie, is die res die operateur se werk, en die korrekte skuif aan jou kant is om vir die venster te wag eerder as om die kontrole te verswak.