Certifikát VPN zatím není platný: tři příčiny, jedno pořadí kontroly
Zatím není platný znamená, že hodiny zařízení se zpožďují, okno skutečně začíná později, nebo se zprostředkující certifikát ještě neotevřel. Zkontrolujte je v tomto pořadí.
Otevřete klienta, vyberete profil, který používáte měsíce, a on se zastaví s hláškou „certificate is not yet valid“. Na vašem přihlášení se nic nezměnilo a úložiště důvěry je pravděpodobně v pořádku: certifikát předložený při handshake nese okno platnosti, které začíná později než okamžik, který používá ověřovatel. Přesně tuto zprávu vytvářejí tři různé situace a vyžadují různé kroky. Pořadí níže vám řekne, kterou z nich máte, než se dotknete hodin nebo souboru certifikátu.
Kterou ze tří příčin vidíte
První příčina je místní: zařízení, které kontrolu provádí, má hodiny dřívější než datum začátku certifikátu. Vidíte to na hardwaru s mrtvou baterií CMOS, na virtuálních strojích obnovených ze starého snímku, na zařízeních, která byla vypnutá dost dlouho, aby ztratila čas, a v sítích, kde je odchozí NTP blokován a nikdo si toho nevšiml. Certifikát může být zcela platný a přesto takto selhat.
Druhá příčina patří vydavateli, protože certifikát skutečně začíná v budoucnosti: vydán brzy, vygenerován s explicitním časem začátku nebo podepsán jako součást aktivačního kroku, který ještě neproběhl. Třetí příčina ztrácí nejvíce času, protože koncový certifikát je aktuální, zatímco jiný certifikát v předloženém řetězu ne, takže chyba pojmenovává materiál, který jste nikdy nenainstalovali.
Odděluje je jedna otázka. Sleduje selhání zařízení, nebo službu? Dva stroje ve stejné síti, které se chovají různě, ukazují na hodiny. Když selhává každý klient stejně, ukazuje to na okno certifikátu a řetěz za ním.
Přečtěte okno z certifikátu, který byl skutečně předložen
Neprohlížejte soubor PEM zbylý z dřívějšího nasazení; požádejte službu o řetěz, který posílá právě teď. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts vypíše každý certifikát v řetězu. Uložte blok, který vás zajímá, a spusťte openssl x509 -noout -subject -issuer -dates; poslední vypíše notBefore a notAfter, a to jsou dvě hodnoty, které to rozhodují. Ve Windows dialog certifikátu pro připojení a certutil -dump na exportovaném souboru ukazují stejná pole.
Čtěte oba konce okna, ne jen začátek. Certifikát, který se otevírá za dvě hodiny, a ten, který se za dvě hodiny zavírá, selhávají s různými zprávami a zapojují různé týmy. Poznamenejte si, který certifikát chyba pojmenovává — koncový, zprostředkující, nebo kořenový — protože to rozhoduje, zda lze na straně klienta vůbec něco opravit.
Okno můžete otestovat i bez čekání. Ověřování přijímá explicitní čas: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem vyhodnotí řetěz k tomuto časovému razítku. Spusťte ho s aktuálním časem, abyste selhání reprodukovali, a potom s časem začátku certifikátu, abyste potvrdili, že stejný řetěz projde, jakmile se okno otevře. RFC 5280 definuje pole platnosti a pravidlo, že certifikát se mimo něj nesmí používat, a přesně toto pravidlo váš klient právě uplatnil.
Vaše hodiny, nebo jejich
Porovnejte hodiny zařízení se začátkem certifikátu v UTC, ze zdroje, kterému věříte. date -u dává okamžik a timedatectl status na hostiteli se systemd také hlásí, zda jsou hodiny synchronizované. Ve Windows w32tm /query /status ukazuje aktuální zdroj a poslední úspěšnou synchronizaci. Časové pásmo v oznamovací oblasti je volba zobrazení, ne špatné hodiny; ověřovatel porovnává okamžiky UTC.
| 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 |
Jsou-li hodiny pozadu, resynchronizujte a znovu otestujte, než změníte jakýkoli materiál certifikátu. Zařízení, které je o minuty nebo hodiny vedle, odmítá každý nedávno vydaný certifikát, na který narazí, ne jen jednu službu, takže vysvětlení jednou službou je obvykle to špatné. Pokud jsou hodiny správné a synchronizované, přestaňte se dívat na zařízení: okno patří vydavateli a žádné místní nastavení se kvůli jeho průchodu nemá upravovat.
Tato tabulka je celé rozhodnutí. Posunout hodiny na to, co certifikát očekává, není oprava, a vypnutí časových kontrol také ne, protože obojí skrývá stav, který chybu způsobil.
Proč řetěz selhává, i když koncový certifikát vypadá dobře
Obnovené koncové certifikáty a náhradní zprostředkující certifikáty se obvykle dodávají společně a ne vždy přistanou ve stejný okamžik. Služba může poslat nový koncový certifikát podepsaný zprostředkujícím, jehož vlastní okno začíná později, nebo dál obsluhovat starší zprostředkující pod čerstvým koncovým certifikátem. V obou případech řetěz selhává, zatímco vlastní data koncového certifikátu vypadají rozumně.
Koncové body s vyrovnáváním zátěže to mění z rozbitého na nekonzistentní. Pokud opakování uspěje, nebo jedna síť funguje a jiná ne, poznamenejte si, který peer odpověděl a který řetěz poslal, než změníte nastavení. openssl s_client vypíše připojenou adresu, takže několik pokusů ukáže, zda každý uzel obsluhuje stejný řetěz.
Cesty opravy, které zachovají ověřování
Problém s hodinami se opraví na zařízení a ověřování zůstane zapnuté. Problém s certifikátem opraví operátor materiálem vydaným pro okno, které už zahrnuje teď. Žádné nastavení klienta neudělá z dosud neplatného certifikátu platný; přepínače, které přeskakují časové kontroly, existují proto, abyste potvrdili diagnózu, ne abyste je nasazovali.
Když je certifikát připraven pro plánovanou aktivaci, postupujte podle plánu přechodu. Nainstalujte ho, až se jeho okno otevře, nebo použijte postup překryvu, který dodavatel dokumentuje, místo abyste ho instalovali brzy a učili uživatele proklikat varování. Varování, která se lidé naučí ignorovat, stojí víc než krátké zpoždění.
Nakonec otestujte znovu tak, jak selhání vzniklo: nová relace, stejný klient, zdroj, který skutečně potřebujete. Knihovny TLS mohou ukládat ověřený řetěz po celou dobu života spojení a obnovená relace ho nemusí znovu kontrolovat, takže stará relace může po opravě dál selhávat nebo po regresi dál fungovat. Soubor, který se otevře v prohlížeči, dokazuje jen, že je čitelný; dokončený handshake dokazuje, že se řetěz ověřuje.
Než tiket zavřete, potvrďte čtyři věci: čas UTC a stav synchronizace selhávajícího zařízení, notBefore a notAfter každého certifikátu v předloženém řetězu, stejný řetěz z druhého klienta a název, který chyba certifikátu dává. Pokud jsou hodiny správné a okno se ještě neotevřelo, zbytek je práce operátora a správný krok na vaší straně je počkat na okno, místo abyste kontrolu oslabili.