VPN-certificaat nog niet geldig: drie oorzaken, één controleorde
Nog-niet-geldig betekent dat de klok van het apparaat achterloopt, dat het venster echt later begint, of dat een tussenliggend certificaat nog niet is geopend. Controleer ze in die volgorde.
U opent de client, kiest het profiel dat u al maanden gebruikt, en hij stopt met "certificate is not yet valid". Aan uw aanmelding is niets veranderd, en de vertrouwensopslag is waarschijnlijk in orde: het certificaat dat in de handshake wordt gepresenteerd, draagt een geldigheidsvenster dat later begint dan het moment dat de verificateur gebruikt. Drie verschillende situaties produceren precies die melding, en ze vragen om verschillende acties. De volgorde hieronder vertelt u welke u hebt voordat u een klok of een certificaatbestand aanraakt.
Welke van de drie oorzaken u ziet
De eerste oorzaak is lokaal: het apparaat dat de controle uitvoert, heeft een klok die eerder is dan de begindatum van het certificaat. U ziet het op hardware met een lege CMOS-batterij, op virtuele machines die van een oude momentopname zijn hersteld, op apparaten die lang genoeg uit stonden om de tijd te verliezen, en op netwerken waar uitgaande NTP is geblokkeerd en niemand het merkte. Het certificaat kan volledig geldig zijn en toch op deze manier mislukken.
De tweede oorzaak hoort bij de uitgever, omdat het certificaat echt in de toekomst begint: vroeg uitgegeven, gegenereerd met een expliciete starttijd, of ondertekend als onderdeel van een activeringsstap die nog niet is uitgevoerd. De derde oorzaak kost de meeste tijd, omdat het blad actueel is terwijl een ander certificaat in de gepresenteerde keten dat niet is, dus noemt de fout materiaal dat u nooit hebt geïnstalleerd.
Eén vraag scheidt ze. Volgt de fout het apparaat of de dienst? Twee machines op hetzelfde netwerk die zich anders gedragen, wijzen op klokken. Elke client die op dezelfde manier faalt, wijst op het venster van het certificaat en de keten erachter.
Lees het venster uit het certificaat dat werkelijk is gepresenteerd
Inspecteer geen PEM-bestand dat van een eerdere uitrol is achtergebleven; vraag de dienst om de keten die hij nu stuurt. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts drukt elk certificaat in de keten af. Bewaar het blok dat u nodig hebt en voer openssl x509 -noout -subject -issuer -dates uit; de laatste drukt notBefore en notAfter af, en die twee waarden beslissen. Op Windows tonen het certificaatdialoogvenster voor de verbinding en certutil -dump op een geëxporteerd bestand dezelfde velden.
Lees beide uiteinden van het venster, niet alleen het begin. Een certificaat dat over twee uur opent en een dat over twee uur sluit, falen met verschillende meldingen en betrekken verschillende teams. Noteer welk certificaat de fout noemt — blad, tussenliggend of wortel —, want dat bepaalt of er aan de clientzijde überhaupt iets te repareren is.
U kunt het venster ook testen zonder erop te wachten. Verificatie accepteert een expliciete tijd: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem evalueert de keten op dat tijdstempel. Voer het uit met de huidige tijd om de fout te reproduceren, en daarna met de starttijd van het certificaat om te bevestigen dat dezelfde keten slaagt zodra het venster opent. RFC 5280 definieert het geldigheidsveld en de regel dat een certificaat daarbuiten niet mag worden gebruikt, en dat is precies de regel die uw client zojuist heeft toegepast.
Uw klok, of de hunne
Vergelijk de klok van het apparaat met het begin van het certificaat in UTC, uit een bron die u vertrouwt. date -u geeft het moment, en timedatectl status op een systemd-host meldt ook of de klok is gesynchroniseerd. Op Windows toont w32tm /query /status de huidige bron en de laatste geslaagde synchronisatie. Een tijdzone in de taakbalk is een weergavekeuze, geen verkeerde klok; de verificateur vergelijkt UTC-momenten.
| 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 |
Als de klok achterloopt, synchroniseer dan opnieuw en test opnieuw voordat u certificaatmateriaal wijzigt. Een apparaat dat minuten of uren verkeerd staat, weigert elk recent uitgegeven certificaat dat het tegenkomt, niet alleen één dienst, dus een verklaring met één dienst is meestal de verkeerde. Als de klok correct en gesynchroniseerd is, stop dan met naar het apparaat te kijken: het venster is van de uitgever, en geen lokale instelling mag worden aangepast om het te laten slagen.
Die tabel is de hele beslissing. De klok naar wat het certificaat verwacht verzetten is geen reparatie, en tijdscontroles uitschakelen ook niet, omdat beide de toestand verbergen die de fout veroorzaakte.
Waarom de keten faalt terwijl het blad er goed uitziet
Vernieuwde bladen en vervangende tussenliggende certificaten worden meestal samen geleverd, en ze landen niet altijd op hetzelfde moment. Een dienst kan een nieuw blad sturen dat is ondertekend door een tussenliggend certificaat waarvan het eigen venster later begint, of een ouder tussenliggend certificaat onder een vers blad blijven serveren. Hoe dan ook faalt de keten terwijl de eigen datums van het blad redelijk lijken.
Belastingverdeelde eindpunten maken dit van kapot naar inconsistent. Als een nieuwe poging slaagt, of één netwerk werkt terwijl een ander dat niet doet, noteer dan welke peer antwoordde en welke keten hij stuurde voordat u instellingen wijzigt. openssl s_client drukt het verbonden adres af, dus een paar pogingen onthullen of elk knooppunt dezelfde keten serveert.
Reparatiepaden die de verificatie intact laten
Een klokprobleem wordt op het apparaat opgelost met verificatie ingeschakeld. Een certificaatprobleem wordt door de operator opgelost met materiaal dat is uitgegeven voor een venster dat nu al omvat. Geen enkele clientinstelling maakt een nog-niet-geldig certificaat geldig; de vlaggen die tijdscontroles overslaan bestaan om een diagnose te bevestigen, niet om ze uit te rollen.
Wanneer het certificaat is voorbereid voor een geplande activering, volg het overgangsplan. Installeer het wanneer het venster opent, of gebruik de overlap-procedure die de provider documenteert, in plaats van het vroeg te installeren en gebruikers te leren door waarschuwingen heen te klikken. Waarschuwingen die mensen leren negeren, kosten meer dan een korte vertraging.
Test ten slotte opnieuw zoals de fout ontstond: een nieuwe sessie, dezelfde client, de bron die u echt nodig hebt. TLS-bibliotheken kunnen een geverifieerde keten cachen voor de levensduur van een verbinding, en een hervatte sessie controleert die niet noodzakelijk opnieuw, dus een oude sessie kan na de reparatie blijven falen of na een regressie blijven werken. Een bestand dat in een viewer opent, bewijst alleen dat het bestand leesbaar is; een voltooide handshake bewijst dat de keten valideert.
Voordat u het ticket sluit, bevestig vier dingen: de UTC-tijd en synchronisatiestatus van het falende apparaat, de notBefore en notAfter van elk certificaat in de gepresenteerde keten, dezelfde keten van een tweede client, en de naam die de fout aan het certificaat geeft. Als de klok juist is en het venster nog niet is geopend, is de rest het werk van de operator, en de juiste stap aan uw kant is wachten op het venster in plaats van de controle te verzwakken.