Jak zkontrolovat vypršení SSL certifikátu

Rychlý způsob: zámek a online kontrola

V libovolném prohlížeči klikněte na zámek v adresním řádku, otevřete podrobnosti certifikátu a přečtěte si "platný od" a "platný do". Zabere to deset vteřin a ukáže vám to, co vidí váš vlastní prohlížeč. Omezení je v tom, že to pokrývá jen certifikát, který vám byl doručen, z okrajového uzlu nebo serveru, na který jste zrovna narazili, v okamžiku, kdy jste se dívali.

Online SSL kontrola provede stejný handshake zvenčí vaší sítě a nahlásí datum vypršení, vydavatele, jména, na která se certifikát vztahuje, a zda je doručený řetězec kompletní. Poslední bod prohlížeče skrývají, takže vám vnější kontrola řekne něco, co zámek neumí.

Ruční způsob pomocí openssl

Jeden příkaz vypíše okno platnosti:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -dates -subject -issuer

Přepínač -servername posílá SNI, na čemž záleží, protože většina serverů hostuje na jedné adrese více certifikátů a bez něj vám vydá ten nesprávný. Výstup uvádí notBefore a notAfter v UTC, plus pro koho je certifikát vydán a kdo ho vydal.

Chcete-li vidět celý řetězec, který server posílá, ne jen koncový certifikát:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Přečtěte si blok "Certificate chain" nahoře: měli byste vidět koncový certifikát a poté jeden nebo více mezilehlých. Řádek "verify error: unable to get local issuer certificate" znamená, že server neposílá mezilehlý certifikát, což řada prohlížečů tiše obejde, ale řada API klientů, mobilních aplikací a starších systémů ne.

Koncový certifikát, řetězec a co vlastně vyprší

V běžném HTTPS spojení figurují tři certifikáty a každý má vlastní datum vypršení:

• Koncový certifikát je vydán pro vaši doménu. Je krátkodobý, typicky 90 dní u automatizovaného vydávání a až zhruba rok u zakoupeného, a je to to, co lidé myslí pod pojmem "certifikát".
• Mezilehlý certifikát podepisuje koncový certifikát a server ho musí posílat spolu s ním. Vydrží roky, a právě proto, že se mění tak zřídka, jeho vypršení zaskočí týmy nejčastěji.
• Kořenový certifikát žije v úložišti důvěry klienta, ne na vašem serveru. Když kořenový certifikát vyprší nebo přestane být důvěryhodný, starší zařízení, která aktualizaci nikdy nedostala, začnou selhávat, zatímco aktuální zařízení fungují v pořádku, což vytváří výpadek, který z vašeho vlastního notebooku vypadá nemožný.

Ověřujte tedy celý řetězec, ne jen datum u koncového certifikátu. Koncový certifikát se dvěma zbývajícími měsíci na rozbitém řetězci u některých klientů už teď selhává.

Proč je vypršení nejčastější preventabilní výpadek

Vypršení certifikátu je neobvykle škodlivé selhání. Selže úplně, ne postupně, protože prohlížeč spojení rovnou odmítne a místo webu zobrazí varování na celou obrazovku. Okamžik, kdy k tomu dojde, byl daný už v den vydání certifikátu, a to datum nikdo nesledoval. Zároveň sráží najednou vše, co dané jméno používá, nejen web: API, backendy mobilních aplikací, webhooky a integrace. Selhané platební callbacky a rozbité integrace často stojí víc než samotný viditelný výpadek.

Zároveň se mu dá zcela předejít, a proto je to selhání, u kterého se automatizovaná kontrola vyplatí nejvíc.

Jak i automatické obnovení přesto selhává

Automatizované vydávání odstranilo většinu vypršení a přineslo sadu selhání, která se hůř odhalují:

• Obnova proběhla, ale nic se nenačetlo znovu. Nový certifikát leží na disku, zatímco webový server dál z paměti podává starý, dokud se nerestartuje nebo nenačte znovu.
• Validační výzva se rozbila. Přesměrovací pravidlo, změna firewallu nebo nová CDN před původním serverem zablokuje cestu HTTP výzvy, takže obnova týdny selhává bez viditelného příznaku.
• DNS validace ztratila přihlašovací údaje. API token byl obměněn nebo vypršel a DNS výzva už nedokáže vytvořit svůj záznam.
• Časovač obnovy neběží. Kontejner byl znovu sestaven bez cron úlohy nebo systemd časovače, nebo byl stroj migrován a plán se s ním nepřenesl.
• Obnovil se jen jeden uzel. Za load balancerem má jeden server nový certifikát a druhý stále podává starý, takže selhání vypadá přerušovaně.
• E-maily o obnově chodily člověku, který odešel. Stejný problém, jen ve verzi pro zakoupený certifikát.
• Certifikát se obnovil, ale ne pro všechna jména. Subdoména přidaná později v novém certifikátu chybí, takže jen ten jeden název hostitele selhává.

Každý z těchto případů je zevnitř obnovovacího systému neviditelný a zvenčí zřejmý. To je argument pro kontrolu skutečného handshake, ne pro spoléhání se na vlastní logy automatizace.

Automatizace kontroly

Přečtení data vám dá odpověď platnou pro dnešek, a celý problém s vypršením je v tom, že nastane v den, který si nikdo nevybral ke kontrole. Plánovaný monitoring certifikátů provádí skutečný handshake zvenčí v intervalech, varuje předem daný počet dní před notAfter a zachytí i problémy s řetězcem a názvem hostitele, které kalendářní připomínka nikdy neodhalí. HostTracker upozorňuje e-mailem, SMS, hlasovým hovorem, přes Slack, Telegram a další, takže varování se k někomu dostane dřív než samotné vypršení. Monitoring domény a TLS spouští kontrolu nepřetržitě, nástroj pro SSL kontrolu provede jednorázovou kontrolu a návod jak zkontrolovat, zda je port otevřený se věnuje handshake, který selže dřív, než je certifikát vůbec nabídnut.