VPN-certifikat er endnu ikke gyldigt: tre årsager, én kontrolrækkefølge
Endnu-ikke-gyldigt betyder, at enhedens ur går bagud, at vinduet reelt starter senere, eller at et mellemliggende certifikat endnu ikke er åbnet. Kontrollér dem i den rækkefølge.
Du åbner klienten, vælger den profil, du har brugt i månedsvis, og den stopper med "certificate is not yet valid". Intet ved dit login er ændret, og tillidslageret er sandsynligvis i orden: certifikatet, der præsenteres i håndtrykket, har et gyldighedsvindue, der starter senere end det tidspunkt, verifikatoren bruger. Tre forskellige situationer giver præcis den meddelelse, og de kræver forskellige handlinger. Rækkefølgen nedenfor fortæller dig, hvilken du har, før du rører ved et ur eller en certifikatfil.
Hvilken af de tre årsager du ser på
Den første årsag er lokal: enheden, der udfører kontrollen, har et ur, der er tidligere end certifikatets startdato. Du ser det på hardware med et dødt CMOS-batteri, på virtuelle maskiner gendannet fra et gammelt snapshot, på apparater, der har været slukket længe nok til at miste tiden, og på netværk, hvor udgående NTP er blokeret, og ingen har bemærket det. Certifikatet kan være helt gyldigt og alligevel fejle på denne måde.
Den anden årsag tilhører udstederen, fordi certifikatet faktisk begynder i fremtiden: udstedt tidligt, genereret med et eksplicit starttidspunkt eller signeret som en del af et aktiveringstrin, der ikke er kørt endnu. Den tredje årsag spilder mest tid, fordi bladet er aktuelt, mens et andet certifikat i den præsenterede kæde ikke er, så fejlen nævner materiale, du aldrig installerede.
Et spørgsmål skiller dem. Følger fejlen enheden eller tjenesten? To maskiner på samme netværk, der opfører sig forskelligt, peger på ure. Når hver klient fejler på samme måde, peger det på certifikatets vindue og kæden bag det.
Læs vinduet fra det certifikat, der faktisk blev præsenteret
Undersøg ikke en PEM-fil, der er tilbage fra en tidligere udrulning; spørg tjenesten om den kæde, den sender lige nu. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts udskriver hvert certifikat i kæden. Gem den blok, du har brug for, og kør openssl x509 -noout -subject -issuer -dates; den sidste udskriver notBefore og notAfter, og det er de to værdier, der afgør sagen. På Windows viser certifikatdialogen for forbindelsen og certutil -dump på en eksporteret fil de samme felter.
Læs begge ender af vinduet, ikke kun starten. Et certifikat, der åbner om to timer, og et, der lukker om to timer, fejler med forskellige meddelelser og involverer forskellige teams. Bemærk, hvilket certifikat fejlen nævner — blad, mellemliggende eller rod — fordi det afgør, om noget på klientsiden overhovedet kan rettes.
Du kan også teste vinduet uden at vente på det. Verifikation accepterer et eksplicit tidspunkt: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem evaluerer kæden på det tidspunkt. Kør det med den aktuelle tid for at genskabe fejlen, derefter med certifikatets starttid for at bekræfte, at den samme kæde passerer, når vinduet åbner. RFC 5280 definerer gyldighedsfeltet og reglen om, at et certifikat ikke må bruges uden for det, og det er netop den regel, din klient lige har håndhævet.
Dit ur, eller deres
Sammenlign enhedens ur med certifikatets start i UTC fra en kilde, du stoler på. date -u giver tidspunktet, og timedatectl status på en systemd-vært rapporterer også, om uret er synkroniseret. På Windows viser w32tm /query /status den aktuelle kilde og den sidste vellykkede synkronisering. En tidszone i proceslinjen er et visningsvalg, ikke et forkert ur; verifikatoren sammenligner UTC-tidspunkter.
| 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 |
Hvis uret går bagud, skal du synkronisere igen og teste igen, før du ændrer noget certifikatmateriale. En enhed, der er minutter eller timer forkert, afviser ethvert nyligt udstedt certifikat, den møder, ikke kun én tjeneste, så en forklaring med én tjeneste er normalt den forkerte. Hvis uret er korrekt og synkroniseret, så stop med at se på enheden: vinduet tilhører udstederen, og ingen lokal indstilling bør justeres for at få det til at passere.
Den tabel er hele beslutningen. At flytte sit ur til det, certifikatet forventer, er ikke en reparation, og at slå tidskontroller fra er heller ikke, fordi begge skjuler den tilstand, der frembragte fejlen.
Hvorfor kæden fejler, mens bladet ser fint ud
Fornyede blade og erstatningsmellemcertifikater sendes normalt sammen, og de lander ikke altid i samme øjeblik. En tjeneste kan sende et nyt blad signeret af et mellemliggende certifikat, hvis eget vindue starter senere, eller fortsætte med at betjene et ældre mellemliggende certifikat under et frisk blad. Uanset hvad fejler kæden, mens bladets egne datoer ser rimelige ud.
Loadbalancerede endepunkter gør dette fra i stykker til inkonsistent. Hvis et nyt forsøg lykkes, eller ét netværk virker, mens et andet ikke gør, skal du notere, hvilken peer der svarede, og hvilken kæde den sendte, før du ændrer indstillinger. openssl s_client udskriver den forbundne adresse, så nogle få forsøg afslører, om hver node betjener den samme kæde.
Reparationsveje, der holder valideringen intakt
Et urproblem rettes på enheden med validering slået til. Et certifikatproblem rettes af operatøren med materiale udstedt til et vindue, der allerede omfatter nu. Ingen klientindstilling gør et endnu-ikke-gyldigt certifikat gyldigt; de flag, der springer tidskontroller over, findes for at bekræfte en diagnose, ikke for at sende dem i produktion.
Når certifikatet er klargjort til en planlagt aktivering, følg overgangsplanen. Installér det, når dets vindue åbner, eller brug den overlapningsprocedure, udbyderen dokumenterer, i stedet for at installere tidligt og lære brugerne at klikke advarsler væk. Advarsler, som folk lærer at ignorere, koster mere end en kort forsinkelse.
Til sidst skal du teste igen på den måde, fejlen opstod: en ny session, den samme klient, den ressource, du faktisk har brug for. TLS-biblioteker kan cache en verificeret kæde i hele forbindelsens levetid, og en genoptaget session kontrollerer den ikke nødvendigvis igen, så en gammel session kan fortsætte med at fejle efter rettelsen eller fortsætte med at virke efter en regression. En fil, der åbner i en fremviser, beviser kun, at filen er læsbar; et fuldført håndtryk beviser, at kæden validerer.
Før du lukker sagen, skal du bekræfte fire ting: den fejlende enheds UTC-tid og synkroniseringstilstand, notBefore og notAfter for hvert certifikat i den præsenterede kæde, den samme kæde fra en anden klient og det navn, fejlen sætter på certifikatet. Hvis uret er rigtigt, og vinduet ikke er åbnet, er resten operatørens arbejde, og det korrekte træk fra din side er at vente på vinduet i stedet for at svække kontrollen.