VPN-sertifikat er ennå ikke gyldig: tre årsaker, én kontrollrekkefølge
Ennå-ikke-gyldig betyr at enhetens klokke går bakover, at vinduet faktisk starter senere, eller at et mellomliggende sertifikat ennå ikke er åpnet. Kontroller dem i den rekkefølgen.
Du åpner klienten, velger profilen du har brukt i månedsvis, og den stopper med "certificate is not yet valid". Ingenting ved påloggingen din er endret, og tillitslageret er sannsynligvis i orden: sertifikatet som presenteres i håndtrykket, har et gyldighetsvindu som starter senere enn tidspunktet verifikatoren bruker. Tre forskjellige situasjoner gir nøyaktig den meldingen, og de krever forskjellige tiltak. Rekkefølgen nedenfor forteller deg hvilken du har, før du rører en klokke eller en sertifikatfil.
Hvilken av de tre årsakene du ser på
Den første årsaken er lokal: enheten som utfører kontrollen, har en klokke som er tidligere enn sertifikatets startdato. Du ser det på maskinvare med dødt CMOS-batteri, på virtuelle maskiner gjenopprettet fra et gammelt øyeblikksbilde, på enheter som har vært avslått lenge nok til å miste tiden, og på nettverk der utgående NTP er blokkert og ingen har lagt merke til det. Sertifikatet kan være helt gyldig og likevel feile på denne måten.
Den andre årsaken tilhører utstederen, fordi sertifikatet faktisk begynner i fremtiden: utstedt tidlig, generert med et eksplisitt starttidspunkt eller signert som en del av et aktiveringstrinn som ennå ikke er kjørt. Den tredje årsaken sløser mest tid, fordi bladet er aktuelt mens et annet sertifikat i den presenterte kjeden ikke er det, så feilen navngir materiale du aldri installerte.
Ett spørsmål skiller dem. Følger feilen enheten eller tjenesten? To maskiner på samme nettverk som oppfører seg forskjellig, peker på klokker. Når hver klient feiler på samme måte, peker det på sertifikatets vindu og kjeden bak det.
Les vinduet fra sertifikatet som faktisk ble presentert
Ikke undersøk en PEM-fil som er igjen fra en tidligere utrulling; spør tjenesten om kjeden den sender nå. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts skriver ut hvert sertifikat i kjeden. Lagre blokken du trenger, og kjør openssl x509 -noout -subject -issuer -dates; den siste skriver ut notBefore og notAfter, og det er de to verdiene som avgjør. På Windows viser sertifikatdialogen for tilkoblingen og certutil -dump på en eksportert fil de samme feltene.
Les begge endene av vinduet, ikke bare starten. Et sertifikat som åpner om to timer, og ett som lukker om to timer, feiler med forskjellige meldinger og involverer forskjellige team. Legg merke til hvilket sertifikat feilen navngir — blad, mellomliggende eller rot — fordi det avgjør om noe på klientsiden i det hele tatt kan repareres.
Du kan også teste vinduet uten å vente på det. Verifiseringen godtar et eksplisitt tidspunkt: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem evaluerer kjeden på det tidsstempelet. Kjør det med gjeldende tid for å gjenskape feilen, deretter med sertifikatets starttid for å bekrefte at samme kjede passerer når vinduet åpnes. RFC 5280 definerer gyldighetsfeltet og regelen om at et sertifikat ikke må brukes utenfor det, og det er nettopp regelen klienten din nettopp håndhevet.
Klokken din, eller deres
Sammenlign enhetens klokke med sertifikatets start i UTC, fra en kilde du stoler på. date -u gir tidspunktet, og timedatectl status på en systemd-vert rapporterer også om klokken er synkronisert. På Windows viser w32tm /query /status gjeldende kilde og siste vellykkede synkronisering. En tidssone i oppgavelinjen er et visningsvalg, ikke en feil klokke; 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 klokken går bakover, synkroniser på nytt og test på nytt før du endrer noe sertifikatmateriale. En enhet som er minutter eller timer feil, avviser hvert nylig utstedt sertifikat den møter, ikke bare én tjeneste, så en forklaring med én tjeneste er vanligvis den feilaktige. Hvis klokken er riktig og synkronisert, slutt å se på enheten: vinduet tilhører utstederen, og ingen lokal innstilling bør justeres for å få det til å passere.
Den tabellen er hele avgjørelsen. Å flytte klokken til det sertifikatet forventer, er ikke en reparasjon, og å slå av tidskontroller er heller ikke, fordi begge skjuler tilstanden som produserte feilen.
Hvorfor kjeden feiler mens bladet ser fint ut
Fornyede blad og erstatningsmellomsertifikater sendes vanligvis sammen, og de lander ikke alltid i samme øyeblikk. En tjeneste kan sende et nytt blad signert av en mellomliggende hvis eget vindu starter senere, eller fortsette å betjene en eldre mellomliggende under et ferskt blad. Uansett feiler kjeden mens bladets egne datoer ser rimelige ut.
Lastbalanserte endepunkter gjør dette fra ødelagt til inkonsistent. Hvis et nytt forsøk lykkes, eller ett nettverk fungerer mens et annet ikke gjør det, noter hvilken peer som svarte og hvilken kjede den sendte, før du endrer innstillinger. openssl s_client skriver ut den tilkoblede adressen, så noen få forsøk avslører om hver node betjener samme kjede.
Reparasjonsveier som holder verifiseringen intakt
Et klokkeproblem rettes på enheten med verifisering slått på. Et sertifikatproblem rettes av operatøren med materiale utstedt for et vindu som allerede omfatter nå. Ingen klientinnstilling gjør et ennå-ikke-gyldig sertifikat gyldig; flaggene som hopper over tidskontroller finnes for å bekrefte en diagnose, ikke for å sende dem i produksjon.
Når sertifikatet er klargjort for en planlagt aktivering, følg overgangsplanen. Installer det når vinduet åpnes, eller bruk overlappprosedyren leverandøren dokumenterer, i stedet for å installere tidlig og lære brukerne å klikke seg gjennom advarsler. Advarsler folk lærer å ignorere, koster mer enn en kort forsinkelse.
Til slutt, test på nytt slik feilen oppstod: en ny økt, samme klient, ressursen du faktisk trenger. TLS-biblioteker kan bufre en verifisert kjede for hele tilkoblingens levetid, og en gjenopptatt økt sjekker den ikke nødvendigvis på nytt, så en gammel økt kan fortsette å feile etter rettelsen eller fortsette å virke etter en regresjon. En fil som åpnes i en fremviser, beviser bare at filen er lesbar; et fullført håndtrykk beviser at kjeden validerer.
Før du lukker saken, bekreft fire ting: den feilende enhetens UTC-tid og synkroniseringstilstand, notBefore og notAfter for hvert sertifikat i den presenterte kjeden, samme kjede fra en annen klient, og navnet feilen gir sertifikatet. Hvis klokken er riktig og vinduet ikke er åpnet, er resten operatørens arbeid, og det riktige trekket på din side er å vente på vinduet i stedet for å svekke kontrollen.