VPN-certifikatet är ännu inte giltigt: tre orsaker, en kontrollordning
Ännu-inte-giltigt betyder att enhetens klocka går efter, att fönstret verkligen börjar senare eller att ett mellanliggande certifikat ännu inte har öppnats. Kontrollera dem i den ordningen.
Du öppnar klienten, väljer profilen du använt i månader, och den stannar med "certificate is not yet valid". Inget i din inloggning har ändrats, och förtroendelagret är förmodligen i ordning: certifikatet som presenteras i handskakningen har ett giltighetsfönster som börjar senare än den tidpunkt verifieraren använder. Tre olika situationer ger exakt det meddelandet, och de kräver olika åtgärder. Ordningen nedan säger vilken du har innan du rör en klocka eller en certifikatfil.
Vilken av de tre orsakerna du tittar på
Den första orsaken är lokal: enheten som utför kontrollen har en klocka som är tidigare än certifikatets startdatum. Du ser det på maskinvara med dött CMOS-batteri, på virtuella maskiner återställda från en gammal ögonblicksbild, på enheter som varit avstängda länge nog för att tappa tiden, och i nätverk där utgående NTP är blockerat och ingen har märkt det. Certifikatet kan vara helt giltigt och ändå misslyckas på detta sätt.
Den andra orsaken tillhör utgivaren, eftersom certifikatet verkligen börjar i framtiden: utfärdat tidigt, genererat med en explicit starttid eller signerat som en del av ett aktiveringssteg som ännu inte körts. Den tredje orsaken slösar mest tid, eftersom bladet är aktuellt medan ett annat certifikat i den presenterade kedjan inte är det, så felet namnger material du aldrig installerat.
En fråga skiljer dem. Följer felet enheten eller tjänsten? Två maskiner i samma nätverk som beter sig olika pekar på klockor. Om varje klient misslyckas på samma sätt pekar det på certifikatets fönster och kedjan bakom det.
Läs fönstret från certifikatet som faktiskt presenterades
Inspektera inte en PEM-fil som ligger kvar från en tidigare utrullning; fråga tjänsten om kedjan den skickar nu. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts skriver ut varje certifikat i kedjan. Spara blocket du behöver och kör openssl x509 -noout -subject -issuer -dates; den sista skriver ut notBefore och notAfter, och det är de två värdena som avgör. På Windows visar certifikatdialogen för anslutningen och certutil -dump på en exporterad fil samma fält.
Läs båda ändarna av fönstret, inte bara början. Ett certifikat som öppnas om två timmar och ett som stängs om två timmar misslyckas med olika meddelanden och involverar olika team. Notera vilket certifikat felet namnger — blad, mellanliggande eller rot — eftersom det avgör om något på klientsidan alls kan repareras.
Du kan också testa fönstret utan att vänta på det. Verifieringen accepterar en explicit tid: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem utvärderar kedjan vid den tidsstämpeln. Kör det med aktuell tid för att återskapa felet, sedan med certifikatets starttid för att bekräfta att samma kedja passerar när fönstret öppnas. RFC 5280 definierar giltighetsfältet och regeln att ett certifikat inte får användas utanför det, och det är just den regeln din klient nyss tillämpade.
Din klocka, eller deras
Jämför enhetens klocka med certifikatets start i UTC, från en källa du litar på. date -u ger tidpunkten, och timedatectl status på en systemd-värd rapporterar också om klockan är synkroniserad. På Windows visar w32tm /query /status aktuell källa och senaste lyckade synkronisering. En tidszon i aktivitetsfältet är ett visningsval, inte en felaktig klocka; verifieraren jämför UTC-tidpunkter.
| 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 |
Om klockan går efter, synkronisera om och testa igen innan du ändrar något certifikatmaterial. En enhet som är minuter eller timmar fel avvisar varje nyligen utfärdat certifikat den möter, inte bara en tjänst, så en förklaring med en enda tjänst är oftast den felaktiga. Om klockan är korrekt och synkroniserad, sluta titta på enheten: fönstret tillhör utgivaren, och ingen lokal inställning bör justeras för att få det att passera.
Den tabellen är hela beslutet. Att flytta klockan till det certifikatet förväntar sig är inte en reparation, och att stänga av tidskontroller är det inte heller, eftersom båda döljer tillståndet som producerade felet.
Varför kedjan misslyckas medan bladet ser bra ut
Förnyade blad och ersättande mellanliggande certifikat levereras oftast tillsammans, och de landar inte alltid i samma ögonblick. En tjänst kan skicka ett nytt blad signerat av ett mellanliggande vars eget fönster börjar senare, eller fortsätta att betjäna ett äldre mellanliggande under ett färskt blad. Hur som helst misslyckas kedjan medan bladets egna datum ser rimliga ut.
Lastbalanserade slutpunkter gör detta från trasigt till inkonsekvent. Om ett nytt försök lyckas, eller ett nätverk fungerar medan ett annat inte gör det, notera vilken peer som svarade och vilken kedja den skickade innan du ändrar inställningar. openssl s_client skriver ut den anslutna adressen, så några försök avslöjar om varje nod betjänar samma kedja.
Reparationsvägar som håller verifieringen intakt
Ett klockproblem åtgärdas på enheten med verifieringen påslagen. Ett certifikatproblem åtgärdas av operatören med material utfärdat för ett fönster som redan omfattar nu. Ingen klientinställning gör ett ännu-icke-giltigt certifikat giltigt; flaggorna som hoppar över tidskontroller finns för att bekräfta en diagnos, inte för att rullas ut.
När certifikatet är förberett för en planerad aktivering, följ övergångsplanen. Installera det när dess fönster öppnas, eller använd överlappningsproceduren som leverantören dokumenterar, i stället för att installera det tidigt och lära användarna att klicka sig genom varningar. Varningar som folk lär sig ignorera kostar mer än en kort fördröjning.
Testa till sist igen på samma sätt som felet uppstod: en ny session, samma klient, resursen du faktiskt behöver. TLS-bibliotek kan cacha en verifierad kedja under hela anslutningens livstid, och en återupptagen session kontrollerar den inte nödvändigtvis igen, så en gammal session kan fortsätta misslyckas efter åtgärden eller fortsätta fungera efter en regression. En fil som öppnas i en visare bevisar bara att filen är läsbar; en slutförd handskakning bevisar att kedjan validerar.
Innan du stänger ärendet, bekräfta fyra saker: den felande enhetens UTC-tid och synkroniseringsstatus, notBefore och notAfter för varje certifikat i den presenterade kedjan, samma kedja från en andra klient, och namnet felet ger certifikatet. Om klockan är rätt och fönstret inte har öppnats är resten operatörens arbete, och det riktiga draget på din sida är att vänta på fönstret i stället för att försvaga kontrollen.