Zapnout HTTPS a zapnout HSTS nejsou stejná rozhodnutí. HTTPS zabezpečuje spojení; HSTS ukládá prohlížeči pravidlo, aby se k danému jménu připojoval přes HTTPS i při dalších návštěvách. Tím pomáhá omezit návrat k nezabezpečenému spojení, ale také zvyšuje důsledky chybného certifikátu. Provozovatel magazínu proto potřebuje nejdříve prověřit celý rozsah pravidla a teprve potom prodlužovat jeho platnost.
Co se po přijetí hlavičky změní
Server posílá zásadu hlavičkou Strict-Transport-Security v odpovědi přes HTTPS. Prohlížeč si ji může zapamatovat na dobu určenou parametrem max-age. Při další návštěvě podle této zásady přechází na zabezpečené spojení. MDN zároveň vysvětluje, že při chybě certifikátu prohlížeč pod HSTS nedovolí obvyklé obejití varování.
Pro redakci to znamená jednoduchou provozní podmínku: obnova certifikátů musí fungovat dříve než dlouhodobá zásada. HSTS neopravuje chybný certifikát, směrování ani nefunkční server. Pokud selže HTTPS, nelze plánovat návrat návštěvníků na HTTP jako běžnou nouzovou variantu. Připravený návrat má zachovat funkční zabezpečené spojení.
Samotná hlavička také neřeší všechny požadavky uvnitř článku. Staré vložené HTTP adresy je vhodné opravit u zdroje. Souvislost vysvětluje návod na smíšený obsah ve WordPressu. Provozní přejímka má proto odlišit správnou zásadu od skutečně fungující stránky se všemi potřebnými prvky.
Před includeSubDomains udělejte inventuru
Parametr includeSubDomains rozšiřuje zásadu na subdomény příslušného jména. Na hlavní doméně tak může ovlivnit i služby, které redakce běžně nevidí: starý archiv, firemní portál, zákaznickou aplikaci nebo pomocný nástroj. Jejich provozovatelé musí o plánované změně vědět a potvrdit funkční HTTPS v potřebném rozsahu.
Nepleťte si subdomény s cestami článků. Adresa magazin.example.test/archiv je cesta na stejném jméně, zatímco archiv.example.test je samostatné jméno. Pro inventuru potřebujete druhou skupinu včetně vnořených subdomén. Seznam v redakčním menu nestačí: mohou existovat služby přístupné jen zaměstnancům nebo dodavatelům.
| Oblast | Co ověřit před změnou | Kdo má potvrdit výsledek |
|---|---|---|
| Hlavní web a www | HTTPS, přesměrování a certifikáty obou jmen | Správce webové infrastruktury |
| Redakční nástroje | Používané subdomény a přihlášení | Správce každé služby |
| Externě provozované aplikace | Podpora a obnova HTTPS pro vlastní doménu | Dodavatel aplikace |
| Opuštěné služby | Zda ještě mají uživatele či závislosti | Vlastník původního projektu |
Nasazujte po ověřitelných krocích
Konkrétní konfigurace závisí na serveru, hostingu a případné CDN. Není rozumné vložit několik různých variant hlavičky současně do šablony, pluginu a proxy. Nejprve zjistěte, která vrstva ji vytváří. Jedno srozumitelné místo správy pomůže při změně i pozdějším odstraňování závady.
- Ověřte stabilní HTTPS a obnovu certifikátů pro zamýšlený rozsah.
- Uložte dosavadní odpovědi a určete vrstvu, která bude hlavičku posílat.
- Zvolte počáteční omezenou dobu platnosti podle možností kontroly a návratu.
- Otestujte veřejnou odpověď, různé typy stránek a potřebné služby.
- Po stabilním provozu zvažte delší dobu a samostatně posuďte subdomény.
Omezená počáteční platnost není univerzální magické číslo. Musí dávat smysl pro vaše prostředí a čas potřebný k odhalení problému. Stejně tak kontrola jedné odpovědi bez chyby nepotvrzuje všechny domény. U změny nastavení si uložte čas, rozsah, původní hodnotu a skutečně vyzkoušené adresy.
Proč smazání hlavičky nemusí stačit
Prohlížeč může dříve přijatou zásadu uchovávat do vypršení její platnosti. Když server přestane hlavičku posílat, neznamená to automatické vymazání uloženého pravidla u návštěvníků. MDN popisuje zrušení prostřednictvím max-age=0 přijatého přes fungující HTTPS. To však předpokládá, že se klient k danému jménu vůbec bezpečně připojí.
Samostatné zásady subdomén mohou přetrvat i po změně nadřazeného jména. Návrat proto plánujte pro konkrétní hosty, nikoli jen jedním zásahem na homepage. U chybného certifikátu je prioritou obnovit funkční HTTPS. Mazání nastavení na serveru samo nevyřeší pravidlo, které už mají klienti uložené.
Do provozního postupu zahrňte i situaci, kdy tým přístup k nové vrstvě nemá. Pokud hlavičku spravuje CDN, správce samotného WordPressu nemusí mít pravomoc ji změnit. Přehled vlastníků tedy není administrativní formalita: určuje, kdo může při závadě skutečně zasáhnout a jak rychle získá potřebné podklady.
Preload posuzujte jako další samostatný závazek
Při běžném HSTS existuje rozdíl mezi návštěvníkem, který zásadu už přijal, a tím, který na web přichází poprvé. Preload pracuje se seznamem zabudovaným do podporujících prohlížečů a může tento počáteční rozdíl omezit. Není to jen jiné pojmenování běžné hlavičky ani povinná součást každého webu.
Před případným zařazením ověřte aktuální podmínky a důsledky pro hlavní doménu i subdomény. Požadavek na odstranění ze seznamu neznamená okamžitou změnu ve všech již nainstalovaných prohlížečích. Pro malý magazín bývá nejdříve důležitější dobře spravované HTTPS a jasná odpovědnost než rychlé odškrtnutí dalšího bezpečnostního ukazatele.
- Máme úplný seznam relevantních subdomén a jejich správců?
- Umíme udržet HTTPS i při změně hostingu nebo dodavatele aplikace?
- Víme, odkud se hlavička posílá a kdo smí nastavení změnit?
- Rozumíme tomu, že uložená zásada a případný preload mají odlišný návrat?
Modelové rozhodnutí malé redakce
Redakce v modelu provozuje hlavní magazín přes HTTPS, ale jedna starší subdoména slouží partnerům a nemá ověřenou obnovu certifikátu. To není důvod odkládat evidenci ani opravu služby. Je to důvod nerozšiřovat zásadu bez souhlasu jejího správce. Nejdříve se vyřeší konkrétní závislost a teprve potom společný rozsah.
Přejímka může vypadat následovně: hlavní web má ověřenou hlavičku na veřejné odpovědi, dvě partnerské služby mají potvrzené HTTPS a třetí čeká na dodavatele. Záznam tak neříká „HSTS hotovo všude“. Popisuje skutečný stav a zbývající rozhodnutí. Přesný rozsah kontroly je užitečnější než obecné bezpečnostní skóre.
| Rozhodnutí | Podmínka pro pokračování | Důvod odkladu |
|---|---|---|
| Zásada pro hlavní jméno | Funkční HTTPS a spravovaná obnova | Nestabilní certifikát nebo nejasná konfigurace |
| includeSubDomains | Prověřené služby pod tímto jménem | Neznámá či nevyřešená subdoména |
| Delší max-age | Ověřený provoz a připravená odpovědnost | Chybějící kontrola nebo návratový postup |
| Preload | Pochopené aktuální podmínky a dlouhodobý závazek | Nejisté budoucí využití subdomén |
Časté otázky
Nahradí HSTS přesměrování na HTTPS?
Má jinou roli. Přesměrování je odpověď serveru, zatímco uložená HSTS zásada ovlivňuje další připojení prohlížeče. V praxi potřebujete promyšlené chování obou mechanismů pro konkrétní adresy.
Opraví HSTS neplatný certifikát?
Ne. Naopak může zabránit obejití varování, takže spolehlivé HTTPS je předpoklad. Při problému obnovte správný certifikát a ověřte veřejné spojení místo plánování přechodu na nezabezpečenou variantu.
Musím použít includeSubDomains?
Ne automaticky. Parametr rozšiřuje důsledky na další jména pod daným hostem. Nejprve potřebujete jejich inventuru a ověřenou podporu HTTPS, včetně služeb spravovaných jinými dodavateli.
Stačí při návratu hlavičku smazat?
Nemusí. Klienti mohou dřívější zásadu uchovávat do vypršení. Zrušovací zásada se musí doručit přes fungující HTTPS a samostatné zásady subdomén mohou vyžadovat další posouzení.
Má být každý firemní web v preload seznamu?
Takový univerzální závěr neplatí. Jde o samostatné rozhodnutí s širšími provozními důsledky. Nejdříve ověřte stabilní HTTPS, správu všech dotčených služeb a aktuální podmínky zařazení i odstranění.
