Váš VPN certifikát dnes vyprší: co vlastně přestane fungovat

Upozornění na vypršení se spustí, tunel stále přenáší provoz a nikdo se neshodne, zda na datu záleží. Záleží, ale ne vždy v okamžiku vytištěném na certifikátu. Vypršelý certifikát zastaví nová ověřování a zastaví revalidace, které některé implementace provádějí uvnitř dlouhé relace. Zda váš stávající tunel o půlnoci zemře, závisí na protokolu, klientovi a nastavení opětovného vyjednávání na serveru. Naplánujte obnovu před datem a ověřte ji novým přihlášením, ne relací, která už byla otevřená.

Zjistěte, který certifikát skutečně vyprší

Nasazení obsahuje serverový koncový certifikát, klientské přihlašovací údaje, jeden nebo více zprostředkujících certifikátů a kořen důvěry, a nevyprší společně. Čtěte certifikát uvedený v chybě a řetězec, se kterým byl předložen, ne první soubor v adresáři profilu. Serverový koncový certifikát, který se čistě obnoví, může stále selhat, pokud zprostředkující certifikát nad ním vypršel. Než cokoli změníte, zapište subjekt, vydavatele, not-after a umístění nasazení každého souboru.

Kořen důvěry je obvykle nejdéle žijící objekt a nejméně pravděpodobná příčina.

Proč živá relace může datum přežít

Ověřování probíhá při navázání spojení a některé protokoly později znovu kontrolují identitu. OpenVPN znovu vyjednává datový kanál podle časovače, takže opětovné vyjednání předkládající vypršelý certifikát selže, i když tunel běží hodiny. Implementace, které nikdy znovu neověřují, mohou nést navázanou relaci za datum vypršení, a proto „stále to funguje“ není důkaz. Ani jedno z těchto chování nelze naplánovat.

Berte datum jako lhůtu pro nová přihlášení a životnost relace jako vypůjčený čas.

Zkontrolujte hodiny, než obviníte certifikát

Platnost se vyhodnocuje proti místním hodinám, takže zařízení se špatným časem hlásí selhání platnosti u zcela aktuálního certifikátu. Zkontrolujte klienta, server a jakékoli zařízení na cestě.

Hodiny, které se při spuštění resetují, vysvětlují poruchy, jež se objeví jen po výpadku napájení.

Obnovte prostřednictvím úřadu, který jej vydal

Zachovejte identitu, zamýšlený účel a kompatibilní konfiguraci klíče. Pokud obnova zavádí nového vydavatele nebo připnutý certifikát, klienti potřebují koordinovanou aktualizaci důvěry, ne výměnu souboru na serveru. Chraňte soukromé klíče během vydávání a distribuce, protože obnovený certifikát nezruší kompromitovaný starý klíč. Reset hesla není obnova, ať tiket říká cokoli.

Zveřejněte nový řetězec úplně, protože koncový certifikát bez zprostředkujícího je poloviční obnova, která funguje jen na strojích, jež jej už mají v cache.

Dokažte to novým přihlášením, udržujte možnost návratu

Po nasazení navážte nové povolené spojení z reprezentativního klienta a vyzkoušejte skutečnou aplikaci. Zkontrolujte, že řetězec je doručen tak, jak klienti očekávají, a že jakékoli informace o odvolání jsou dostupné. Udržujte návrat, který nezávisí na důvěře ve vypršelý materiál, abyste se mohli vrátit do předchozího stavu bez oslabení ověřování. Zastaralé soubory odstraňte až po ověření náhrady.

Stávající relace mohou stále odrážet dřívější stav, takže nic nedokazují ani jedním směrem.

Pořadí, které v ten den používám

Potvrďte vypršující objekt a jeho řetězec, poté potvrďte hodiny:

• Který certifikát vyprší a do kterého řetězce patří.
• Zda je každý zprostředkující certifikát nasazen a zveřejněn.
• Hodiny klienta a serveru se shodují v rozumné míře.
• Nové přihlášení uspěje z reprezentativního klienta.
• Informace o odvolání je dostupná.
• Existuje návrat, který neoslabuje ověřování.

Poté obnovte, nasaďte celý řetězec, otestujte novým přihlášením a teprve potom uklidte. Doby platnosti a pravidla jejich vyhodnocování jsou definovány v RFC 5280 a datum není překvapením, pokud vaše monitorování sledovalo objekt, který skutečně vyprší.