První IT magazín psaný manažery z praxe.
Let's Encrypt oznámila postupné zkrácení výchozí platnosti certifikátů z 90 na 64 a později 45 dní. V září 2026 je profil s platností 45 dní dostupný pro zájemce, zatímco změna výchozího profilu teprve přijde. Kratší cyklus zvýrazní starý provozní problém: úspěšné vydání certifikátu ještě neznamená, že jej používá správná služba a že se všechny její instance včas obnovily.
Let's Encrypt zveřejnila harmonogram: profil tlsserver vydává 45denní certifikáty jako volitelná cesta od května 2026; výchozí classic profil má přejít na 64 dní v únoru 2027 a na 45 dní v únoru 2028. Provozní plán proto musí rozlišit, jaký profil skutečně používá konkrétní služba. Není správné dnes všem oznámit, že každý certifikát už má jen 45 dní. Je však rozumné začít ověřovat, zda systém zvládne podstatně častější obnovu bez ručního zásahu.
Kratší platnost omezuje dobu, po kterou zůstane kompromitovaný certifikát použitelný, současně ubírá čas na opravu neúspěšné obnovy. Pro tým je důležitá rezerva mezi plánovanou obnovou a expirací, počet nezávislých pokusů, přístup k DNS nebo HTTP výzvě a chování při nedostupnosti autority. Let’s Encrypt výslovně doporučuje monitorovat očekávané obnovy. Samotný e-mail o blížící se expiraci nemá být hlavním mechanismem řízení.
| Krok obnovy | Co ověřit | Typické selhání |
|---|---|---|
| Ověření domény | Funkční DNS-01 nebo HTTP-01 a platné oprávnění | Rotovaný DNS klíč či nedostupné API |
| Vydání | Nový certifikát se správným jménem a řetězcem | Úspěšný běh jen v testovacím profilu |
| Distribuce | Stejná nová verze na všech uzlech a edge | Zapomenutý proxy uzel nebo jiné úložiště |
| Použití klientem | Skutečné TLS spojení s novým certifikátem | Chybějící opětovné načtení, SNI nebo starý řetězec |
PROVOZNÍ PRAVIDLO
Certifikát označte za obnovený až po ověření skutečným TLS klientem na každém důležitém koncovém bodu. Samotný úspěch ACME klienta uzavírá jen vydání.
Mnoho organizací volí DNS-01, protože certifikát pokrývá více služeb nebo protože HTTP výzvu nelze bezpečně vystavit. ACME klient pak potřebuje právo měnit konkrétní TXT záznam. Příliš široký API klíč pro celou DNS zónu zvětší dopad kompromitace a současně se stane kritickou závislostí obnovy. Udržujte rozsah oprávnění co nejmenší, evidujte jeho vlastníka a ověřte, co se stane při rotaci klíče nebo výpadku DNS API. Obnovovací proces musí selhat viditelně s dostatečným předstihem.
Podobně ověřte, zda testovací a produkční cesta používají stejné doménové záznamy, stejné proxy a stejný deployment mechanismus. Úspěch v testovacím prostředí nemusí předpovědět chování produkčního edge, pokud je certifikát v jiném úložišti. Realistické cvičení by mělo končit připojením skutečného TLS klienta ke každému relevantnímu koncovému bodu.
PRAKTICKÝ TEST
Vynuceně obnovte certifikát před expirací a během distribuce zastavte jeden proxy uzel. Ověřte, zda dohled označí konkrétní službu a vlastníka dřív, než rezerva do expirace klesne pod dohodnutý limit.
ACME klient vystaví nový certifikát a zapíše jej na disk. Monitoring hlásí úspěšný běh. Jeden reverzní proxy uzel ale nedostal pokyn k opětovnému načtení konfigurace, druhý používá certifikát z jiného úložiště a vzdálený konektor stále nabízí starý řetězec. Při expiraci část klientů skončí na chybě TLS podle toho, na jaký uzel je směruje vyvažovač zátěže. Řídicí tým ukazuje log úspěšné obnovy, uživatel vidí nedostupnou službu. Rozdíl je mezi vydáním, distribucí a skutečným podáním certifikátu klientovi.
ACME standardizuje automatizované vydání a ověření kontroly domény. Nezajišťuje za provozovatele správné roznesení klíče, opětovné načtení konfigurace aplikace, správný SNI ani kontrolu všech veřejných a interních hran. Tyto kroky musí být součástí jedné provozní cesty se samostatně měřeným výsledkem.
POZNÁMKA Z PRAXE
Zákazníka nezajímá nový soubor na disku, když vyvažovač dál nabízí starý řetězec. Měřte proto certifikát viděný z klientské strany a sledujte rozdíly mezi uzly.
Centrální PKI tým může provozovat vydání a upozornění, ale jen vlastník služby ví, zda se certifikát používá ještě v mobilní aplikaci, v B2B konektoru nebo v dávkovém rozhraní. Inventář proto musí jít od názvu domény k aplikaci, prostředí a odpovědnému týmu. U expiračního incidentu je tento vztah důležitější než seznam souborů na jednom serveru. Díky němu lze rozhodnout, koho vzbudit a která část zákaznické cesty je ohrožená.
Při plánované změně délky platnosti bych nejprve vybral malý počet služeb a přešel s nimi na kratší profil. Ověřil bych několik úplných obnovovacích cyklů, včetně alertu na chybějící nasazení. Teprve pak bych rozšířil změnu. Takový pilot stojí málo a odhalí slabá místa dřív, než se kratší platnost stane výchozím nastavením pro celou flotilu.
HRANICE DŮKAZU
Úspěšný běh klienta ACME ani přítomnost souboru na serveru neprokazují, že jej používá vyvažovač zátěže, edge a interní služba. Krátký certifikát také není sám o sobě příčinou výpadku; odhaluje neúplnou distribuci a monitoring.
Sledujte datum konce certifikátu, který služba skutečně nabízí z každého veřejného i důležitého interního endpointu. Přidejte kontrolu shody názvu, řetězce a správného certifikátu po opětovném načtení konfigurace. V provozních testech vynuceně obnovte certifikát dlouho před expirací, zastavte jednu distribuční komponentu a ověřte, že alarm identifikuje dotčené služby a vlastníka. U velkých flotil pomůže inventář vazeb doména–certifikát–tajný klíč–nasazení–tým. Bez něj nikdo neví, co se má při problému opravovat první.
Nejdůležitější metrika není počet úspěšných požadavků ACME. Je to podíl koncových bodů, které po každé obnově skutečně nabízejí nový platný certifikát, a nejmenší zbývající rezerva do expirace na celé klientské cestě. Nosná teze zní: kratší platnost sama dobře automatizovanou službu neohrozí; rychleji však odkryje každé místo, kde vydání, distribuce a použití certifikátu nejsou jedním ověřeným procesem.
CIOmag.cz je magazín, a proto je veškerý obsah ve své podstatě reklamou.