Expirace SSL/TLS certifikátu: proč stále shazuje weby

Když TLS certifikát vyprší, prohlížeče přestanou spojení důvěřovat a místo vašeho webu zobrazí varování přes celou obrazovku. API, mobilní aplikace a integrace, které se připojují ke stejnému serveru, obvykle selžou úplně, protože jejich klienti expirovaný certifikát bez ptaní odmítnou. Web sám může běžet bez chyby, pro návštěvníky je ale nedostupný.

Obnova je automatizovaná už roky, tak proč se to stále děje? Protože automatizace pokrývá jen ty certifikáty, na jejichž automatizaci si někdo vzpomněl. Výpadky kvůli expiraci obvykle způsobují ty zapomenuté: subdoména zřízená pro kampaň, load balancer s ručně nahraným certifikátem, poštovní server nebo úloha obnovy, která už týdny potichu selhává.

Platnost certifikátů se navíc zkracuje, takže každá obnova přichází na řadu častěji.

Platnost certifikátů se zkracuje

Pravidla, kterými se řídí veřejně důvěryhodné certifikační autority, stanoví CA/Browser Forum. V dubnu 2025 schválilo hlasování SC-081v3 a aktuální TLS Baseline Requirements (oddíl 6.3.2) stanoví pro maximální platnost certifikátu tento harmonogram:

• vydané před 15. 3. 2026: nejvýše 398 dní,
• vydané od 15. 3. 2026: nejvýše 200 dní,
• vydané od 15. 3. 2027: nejvýše 100 dní,
• vydané od 15. 3. 2029: nejvýše 47 dní.

V praxi to znamená, že do roku 2029 by se ručně obnovovaný certifikát musel měnit zhruba každých 6 až 7 týdnů. Každý certifikát, který se stále obnovuje ručně podle připomínky v kalendáři, je tak opakovaným rizikem výpadku.

Ani na upozornění od certifikační autority se nelze spoléhat. Například Let's Encrypt ukončil e-mailová upozornění na expiraci 4. 6. 2025.

Proč obnova selže

Obvyklé příčiny jsou všední:

• Selže validace. HTTP validace se rozbije po změně přesměrování nebo firewallu, DNS validace po změně poskytovatele DNS nebo po vypršení API tokenu.
• Obnova proběhne, ale služba se nenačte znovu, takže webový server dál předkládá starý certifikát.
• Certifikáty se ručně kopírovaly na load balancer, CDN, zařízení nebo poštovní server, kam automatizace nedosáhne.
• Server nemá vlastníka. Staging servery a staré marketingové subdomény často mají certifikát, ale ne vlastníka. Viz zapomenuté staging a testovací servery.
• Vypršel účet nebo platba za komerční certifikát.
• Řetězec mezilehlých certifikátů je neúplný, což někteří klienti odmítnou ještě před expirací.

Jak si expiraci certifikátu ověřit sami

U jednoho serveru vám openssl ukáže data, která server skutečně předkládá:

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

Dívejte se na notAfter. Každý název kontrolujte zvlášť, včetně www, API a poštovních serverů. U poštovního serveru se STARTTLS:

echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -enddate

Servery, na které jste možná zapomněli, najdete v záznamech Certificate Transparency na crt.sh vyhledáním %.example.com. Je tam uveden každý certifikát vydaný pro vaši doménu, včetně těch pro subdomény, na které si nikdo nevzpomene. Jak výsledky číst, vysvětluje náš článek o záznamech Certificate Transparency.

Jak zabránit expiraci certifikátů

1. Automatizujte vydávání a obnovu přes ACME všude, kde to jde, a zajistěte, aby úloha obnovy poté službu znovu načetla.
2. Obnovujte s dostatečným předstihem, aby zbyl čas opravit neúspěšnou validaci.
3. Upozorňujte na selhání obnovy, nejen na úspěch. Klasickou příčinou je cron úloha, která skončí chybou a nikomu nic neřekne.
4. Mějte soupis všech serverů s certifikátem, sestavený z výsledků Certificate Transparency, ne z paměti.
5. Sledujte zvenčí. Kontrolujte certifikát, který server skutečně předkládá, protože ten vidí klienti. Interní záznam „obnoveno“ není totéž.
6. Odstraňte, co už nepoužíváte. Subdoména, která už nic neposkytuje, by měla přijít o DNS záznam i certifikát.

Když certifikát už vypršel

• Obnovte ho nebo nechte vydat znovu, nasaďte ho a službu znovu načtěte.
• Pomocí openssl s_client mimo svou síť ověřte, že server předkládá nové datum notAfter.
• Zkontrolujte, že server posílá celý řetězec, nejen koncový certifikát.
• Zkontrolujte závislé klienty: u mobilních aplikací, integrací partnerů a webhooků může být potřeba připojení zopakovat.
• Zjistěte, proč se nespustilo upozornění, a opravte to.

Kontrolní seznam

• Soupis všech serverů s certifikáty, včetně poštovních a API serverů.
• Automatizace ACME s opětovným načtením služby.
• Upozornění na neúspěšné obnovy.
• Kontrola expirace zvenčí na každém serveru.
• Připravenost na platnost 100 a 47 dní.

Vypršet mohou i domény, a to s úplně jinými následky. Viz co se stane, když vaše doména vyprší.

Jak pomáhá Datahorses

Datahorses sleduje vaši firmu zvenčí a kontroluje certifikáty, které vaše servery skutečně předkládají, včetně expirace, rozbitých řetězců a certifikátů s vlastním podpisem (self-signed), s připomínkami 30, 14 a 3 dny před vypršením certifikátu nebo domény. Do vašich systémů nevstupujeme a žádné přístupy nepotřebujeme. Podívejte se, co hlídáme, a v ukázkovém přehledu, jak to vypadá.