Web se včera otevíral normálně a dnes prohlížeč varuje před certifikátem. Zapnutá automatická obnova v hostingu přitom ještě neznamená, že návštěvník dostává nový certifikát. Kontrolujte dvě různé věci: úspěšné obnovení a certifikát skutečně nasazený na veřejném webu. U magazínu navíc může spojení obsluhovat CDN, zatímco hosting používá jiný certifikát pro svou část provozu.
Nejdříve sepište místa, která HTTPS obsluhují
Začněte hlavní adresou, variantou s www a používanými subdoménami. Samostatný přihlašovací portál, obrázkový server nebo redakční náhled mohou mít jiného správce. Neodvozujte jejich stav od zeleného výsledku pro titulní stránku. Přesměrování na hlavní adresu také potřebuje fungující HTTPS na výchozím jméně, pokud na něj uživatel přijde přes zabezpečenou adresu.
U každého jména zapište poskytovatele, místo ukončení TLS, způsob obnovy a člověka, který řeší upozornění. Certifikát pro návštěvníka může spravovat CDN a certifikát na původním serveru hosting. Výpadek mezi nimi vypadá jinak než varování přímo v prohlížeči. Jeden úspěšný test proto není inventura celé cesty.
| Místo kontroly | Co potřebujete zjistit | Co samo o sobě nedokazuje |
|---|---|---|
| Veřejný web | Jméno v certifikátu, platnost a důvěryhodnost | Stav certifikátu na původním serveru |
| Hosting nebo server | Obnova, nasazení a případné načtení nové konfigurace | Co právě vrací CDN návštěvníkovi |
| Automatizační úloha | Čas posledního výsledku a konkrétní chyba | Že nový soubor používá běžící služba |
| Upozorňovací kanál | Komu přijde chyba a kdo ji převezme | Že má příjemce právo závadu opravit |
Automatizaci posuzujte podle výsledku
U spravovaného hostingu zjistěte, kdo obnovu provozuje a jak oznamuje chyby. U vlastního serveru musí správce znát ACME klienta, jeho úložiště a způsob nasazení. Samotná existence plánované úlohy nestačí: úloha může běžet pod jiným účtem, nemít oprávnění nebo skončit před načtením nového certifikátu službou.
Nespoléhejte na univerzální tvrzení, že každý certifikát vydrží stejný počet dní. Platnost i doporučený okamžik obnovy se mohou lišit. Pro provoz je užitečnější pravidelně sledovat zbývající platnost, aktuálnost poslední úspěšné obnovy a chybové zprávy. Hranice upozornění nastavte tak, aby tým měl skutečný čas zasáhnout i přes víkend nebo nepřítomnost hlavního správce.
- Obnova: evidujte poslední úspěch a další očekávanou kontrolu, ne jen zapnutý přepínač.
- Nasazení: ověřte, že služba načetla nový certifikát a správný řetězec.
- Dosažitelnost: sledujte veřejnou adresu z prostředí mimo vlastní server.
- Odpovědnost: určete hlavního správce, náhradníka a způsob předání problému.
Proč ověření domény přestane fungovat
ACME služba při vystavování ověřuje kontrolu nad doménou. Podle použité metody potřebuje například dostupný HTTP ověřovací soubor nebo správný DNS TXT záznam. Let’s Encrypt u HTTP-01 používá port 80; DNS-01 může sloužit i pro wildcard certifikáty. Konkrétní podporu a nastavení vždy ověřte u svého klienta a poskytovatele.
Po změně hostingu může ověřovací požadavek chodit na starý server. Po zavedení proxy může pravidlo blokovat potřebnou cestu. DNS automatizaci zase může zastavit odvolaný token. Neřešte všechny příčiny přidáním stále širších oprávnění: DNS přístup omezte na potřebný rozsah a nejdříve zjistěte skutečnou chybu. Přístupový token nepatří do veřejného snímku ani do běžné redakční tabulky.
Základ vztahů mezi registrem, DNS a hostingem vysvětluje průvodce DNS a DNSSEC. Pokud se certifikát přestal obnovovat těsně po přesunu, začněte právě ověřením aktuálního směrování. Platný DNS záznam ovšem ještě nepotvrzuje správné fungování ověřovací cesty.
Co udělat při prvním upozornění
- Otevřete přesnou veřejnou adresu a zaznamenejte čas, hlášené jméno a konec platnosti certifikátu.
- Zjistěte, která služba pro tuto adresu ukončuje TLS a kdo ji spravuje.
- Porovnejte veřejný stav s posledním výsledkem obnovy a nasazení.
- Opravte doloženou příčinu a proveďte přiměřenou kontrolu podle návodu poskytovatele.
- Znovu ověřte veřejný certifikát a uzavřete upozornění až po potvrzení výsledku.
Neopakujte bez rozmyslu ostré vystavování. Certifikační služby mají limity a opakované neúspěšné pokusy nepřinesou diagnózu. Pro ověřování konfigurace používejte testovací prostředí, pokud je poskytovatel nabízí. Testovací certifikát ale není náhradou důvěryhodného certifikátu na veřejném webu.
Modelový problém: soubor je nový, web ukazuje starý
Představme si redakci se samostatným správcem serveru. Automatická úloha úspěšně uloží nový certifikát, ale služba dál používá dříve načtený. Správce má v administraci nový termín, zatímco návštěvník vidí starý. Přidání dalšího připomenutí nic nezmění; chybí kontrola nasazení po obnově.
Ve stejném modelu může CDN ukazovat zdravý veřejný certifikát a současně odmítat spojení s původním serverem. Redakce pak nevidí typické varování prohlížeče, nýbrž chybovou stránku prostředníka. Záznam „HTTPS funguje“ proto doplňte tím, kterou vrstvu jste skutečně prověřili. Jde o modelové situace, nikoli o výsledek testu konkrétního hostingu.
| Zjištěný stav | První směr kontroly | Doklad uzavření |
|---|---|---|
| Obnova dlouho neproběhla | Klient, plánování a ověření domény | Úspěšný výsledek a nový certifikát |
| Obnova prošla, venku je starý certifikát | Nasazení a skutečný koncový server | Nový certifikát na veřejné adrese |
| Veřejný certifikát je platný, CDN hlásí chybu původu | Spojení CDN se serverem | Funkční stránka a ověřená konfigurace původu |
| Selhává jen jedna subdoména | Její samostatný cíl a certifikát | Kontrola právě této adresy |
Jak nastavit užitečná upozornění
Každé upozornění má obsahovat adresu, naměřený problém a odkaz do interního postupu. Vyhněte se hlášení bez kontextu, které každý den oznamuje jen „něco s SSL“. U provozního záznamu oddělte zjištění, zásah a opětovné ověření. Náhradník pak pozná, zda má problém teprve diagnostikovat, nebo zkontrolovat už provedenou opravu.
Po změně CDN, hostingu či DNS zařaďte mimořádnou kontrolu obnovy. Nové prostředí může web správně zobrazit, ale rozbít až příští automatický cyklus. Předání správy proto zahrnuje i způsob vystavení a místo upozornění. Úspěšné otevření homepage při předávce není důkaz budoucí obnovy. Pravidelný přehled má správci ukazovat výjimky, zatímco redakci má být jasné, komu závadu předat.
Časté otázky
Stačí certifikát zkontrolovat v hostingu?
Nestačí. Hosting může ukazovat uložený certifikát, který běžící služba dosud nenačetla. Při použití CDN navíc návštěvník obvykle vidí certifikát této služby. Ověřte přesnou veřejnou adresu a podle zapojení také původní server.
Má každý certifikát stejnou dobu platnosti?
Ne. Nezakládejte provozní kalendář na jednom obecném čísle. Sledujte skutečnou platnost a podporovaný způsob obnovy, včetně doporučení používaného klienta a certifikační služby.
Proč řešit www, když se přesměruje jinam?
Při návštěvě přes HTTPS se musí nejdříve podařit zabezpečené spojení s výchozím jménem. Teprve potom může server poslat HTTP přesměrování. Proto ověřujte i používané přesměrovávané varianty.
Může být příčinou změna DNS?
Ano, například když ověření domény míří jinam, než předpokládá automatizace. Vedle směrování může vystavení ovlivnit i CAA politika. Rozhodující je konkrétní chybová zpráva a skutečná odpověď DNS.
Co má dostat redaktor bez serverového přístupu?
Přesnou adresu, kontakt na správce a jednoduchý postup nahlášení s časem a popisem chyby. Nemusí dostat privilegované přihlašovací údaje. Zásah do certifikátů má provádět člověk s odpovídajícím oprávněním a znalostí daného prostředí.
