Přechod na https

jak již fungující stránky převést na protokol https

Nebo jak stránky od začátku na https provozovat. Tento návod cílím spíše na amatéry než na správce serverů.

Co je potřeba pro přechod stránek na https - Jak postupuji při předělání stránek z http na https - Jak vypadá, když je https v pořádku - Možné stavy rozbitého https - Nastavení certifikátu - Chyba zvaná smíšený obsah - Jak se zbavit smíšeného obsahu načítaného přes http - Přesměrování z http na https - Přechod na https v redakčních systémech - Co udělat po migraci na https

Co je potřeba pro přechod stránek na https

To všechno probírám podrobně níže.

Kolik provoz na https stojí

Záleží na hostingu. Některé hostingy umí zprovoznit https úplně zdarma, typicky na bezplatném certifikátu od Let's Encrypt. Jiné hostingy si i za bezplatný certifikát nechávají platit a jiné hostingy poskytují pouze certifikáty od placených certifikačních agentur.

Předělání stránek by žádné další přímé náklady kromě práce přinést nemělo. Protokoly https a http fungují z uživatelského hlediska v podstatě stejně. I z hlediska kodéra HTML, CSS a javascriptu je http a https vlastně totéž, takže stránky, které fungují na http, mohou normálně fungovat i na https. Záleží samozřejmě na tom, jak dobře nebo špatně jsou udělané. Dobře v tomto případě znamená, že obrázky a další objekty jsou vkládány relativní adresou. Čím víc je v kódu absolutních adres začínajících na http:// a externě vkládaného obsahu, tím hůř se budou stránky předělávat.

Jak postupuji při předělání stránek z http na https

  1. Otevřu si stránku v prohlížeči z internetu a zkusím místo http zadat do adresy https. Takže například místo http://example.com napíšu do prohlížeče prostě https://example.com
  2. Obvykle se objeví nějaká chyba a stránka se vůbec nezobrazí. Na serveru pro doménu není puštěn https protokol, nebo není nainstalovaný certifikát. Ukázky chyb probírám níže.
  3. Chybu pochopím a odstraním ve spolupráci s hostingem, někdy i dost složitě. Opět si otevřu stránku v prohlížeči.
  4. Stránka se sice na https načte, ale prohlížeč bude signalizovat, že stránka obsahuje nějaký nezabezpečený objekt. Říkám tomu "kompromitované https", ale častěji se to nazývá "smíšený obsah". Typicky jde o obrázek, styl nebo skript načítaný z nezabezpečeného http protokolu.
  5. Procházím zdrojové kódy svého webu a hledám v něm výskyty absolutních adres, typicky obrázků a skriptů. Nahrazuji je adresou s https nebo ještě lépe relativní adresou. Občas u toho docela nadávám.
  6. Nakonec se usměje štěstí a v adrese svítí zelený zámeček. Stránka běží na https bez chyb. Takhle zkontroluji celý web.
  7. V tu chvíli stránky běží jak na http, tak na https. Můžu tedy https začít směle propagovat a směrovat na něj odkazy. Teoreticky je možné dlouhodobě provozovat stránky jak na http, tak na https, ale v praxi je mnohem lepší všechny požadavky vedoucí na http přesměrovat na verzi s https.

Jak vypadá, když je https v pořádku

Podoba ikonek v prohlížečích se časem mění. Zde odpovídá zobrazení adresy v roce 2017. V dalších letech se zobrazení adresy a podoba ikonek mění rychleji, než bych stíhal aktualizace. Děkuju za pochopení. Obecně platí, že  prohlížeče už neupozorňují, že stránka je zabezpečená. Spíše se snaží upozornit, když je stránka nezabezpečená.

Abyste byli schopni určit, v jakém stavu se váš web nachází, musíte umět rozpoznat, co znamenají různé barvy a symboly v řádku adresy.

Podle zeleného zámečku a zeleného nápisu https se pozná, že stránka je zabezpečená a https není kompromitované. V tomto případě (i díky dobrému hostingu) zcela zdarma.

Významné firmy si můžou pořídit dražší EV certifikát, u kterého certifikační agentura ručí za to, že web provozuje určitá firma, která skutečně existuje na nějaké planetě (v tomto případě firma Seznam na planetě Zemi). Tento druh certifikátu udělá před adresou velký zelený obdélník s názvem firmy. Pro běh běžných webů zbytečně drahé (větší tisíce ročně pro každou subdoménu). Pro velké korporace rozumná investice.

Od roku 2019 prohlížeče protokol skrývají, takže je dobré si zapnout jeho zobrazování (pravý klik v adrese a zatrhnout "Always show full URL").

Upozornění se od roku 2021 naopak dostává stránkám, které https nemají a jedou jenom na http:

Chrome v roce 2024 píše "Nezabezpečeno", ale dovolí na stránku normálně jít (což je v pořádku; http je protokol, kterého se není třeba bát.) Firefox škrtá zámeček.

Možné stavy rozbitého https

Jak poznáte, v jakém stavu se váš web ohledně https nachází? Zkuste si do své adresy místo http zadat https. (Ukázky snímám z nejpoužívanějšího prohlížeče Chrome v létě 2016.)

Server není vůbec nastaven pro vydávání https

Nápis https v adresním řádku je šedivý, stránka se vůbec nezobrazí. Server neví, že má na protokolu https vůbec něco vydávat. Když se na tutéž stránku jde protokolem http, stránka může normálně odpovídat.

Je potřeba chtít po hostingu, aby https rozběhal. Typicky tak, že začne poslouchat a odpovídat i na portu 443. Některé hostingy to mají v nastavení, jiným se musí posílat autorizovaný požadavek, dalším to stačí mailem.

Chybějící nebo špatný certifikát

Certifikát hlásí chybu. Buďto vůbec neexistuje, nebo je neplatný, případně je vydaný pro jiný subjekt nebo subdoménu. Nápis "https" v adresním řádku je červeně přeškrtnutý. Tuto chybu vídám zejména v případě, že zkusím použít certifikát, který je platný pro doménu hostingové firmy, ale není platný pro moji doménu.

Je potřeba pořídit si certifikát a na serveru ho nainstalovat (typicky pomocí služeb, které poskytuje váš hosting). Tomu se ještě věnuji níže v odstavci o certifikátech. Pokud hosting certifikáty nenabízí, je potřeba stránky přestěhovat k jinému hostingu.

Https je kompromitované - mixed content

Když se v adrese "https" objeví pouze šedivou barvou (případně ve Firefoxu s šedým nebo žlutým vykřičníkem, v Chrome též se šedivým íčkem), znamená to, že stránka je serverem už poskytována na https a certifikát má v pořádku. Ale obsahuje nějaký objekt načítaný nezabezpečeně přes protokol http. V uvedené grafické ukázce je tím objektem obrázek. Útočník, který odposlouchává síť, by teoreticky mohl zjistit, kterou stránku prohlížím, podle toho, že by v otevřené http komunikaci viděl http požadavek na ten obrázek.

Je potřeba stránky upravit tak, aby neobsahovaly obrázky, skripty a styly načítané přes http protokol. Všechny načítané objekty musí jít přes https. Nestačí tedy na https zprovoznit samotnou stránku, je potřeba na https dostat i všechny načítané objekty.

Firefox u mixed content ukazuje šedý vykřičníček.

Chrome u mixed content v roce 2024 už ukazuje varování jenom po rozkliknutí a poněkud krypticky to označuje frází Spojení s tímto webem není plně zabezpečené.

Nastavení certifikátu

Pokud jde o certifikáty, většina amatérů i profesionálů je odkázána na služby svého hostingu. Většinou to funguje takto:

  1. řeknu hostingu (kliknutím v administračním rozhraní, autorizovaným požadavkem, mailem), že mám zájem o certifikát pro nějakou doménu nebo subdoménu
  2. hosting to zařídí, někdy si za to nechá zaplatit
  3. a za pár minut nebo hodin běží web na https (což ve většině případů v tu chvíli znamená, že běží jak na http, tak na https a na obou protokolech poskytuje stejný obsah).

Příklad nastaveného certifikátu na hostingu Endora.cz. Bylo to na jedno kliknutí.

Jak to ten hosting zařídí (tohle můžete přeskočit)

Určitě jste si všimli magického druhého bodu: "hosting to zařídí". Ačkoli to ve většině případů nebudete muset řešit, pojďme si probrat, co to hosting vlastně zařizuje:

  1. Hosting se obrátí na certifikační agenturu. Uvede, pro kterou doménu (konkrétní subdoménu, případně wildcard) chce vystavit certifikát.
  2. Certifikační agentura vystaví certifikát a hostingu ho nějak pošle. Mailem, přes API nebo jinak. (Až na jednu výjimku si za to nechá zaplatit, tou výjimkou je Let's Encrypt.)
  3. Hosting převezme certifikát, nakopíruje si ho na server na správné místo a asociuje ho s doménou. Většinou se to všechno děje automaticky, ale na některých hostinzích to stále dělají ručně.
  4. Hosting nakonfiguruje svůj server tak, aby zpracovával požadavky i přes https. Ve většině případů přitom buď musí doméně vyhradit vlastní IP adresu, nebo nastavit SNI, aby mohlo více domén fungovat přes https na jedné IP adrese.
  5. Hosting zařídí pravidelnou aktualizaci certifikátu.

Teď už tušíte, jak to může být složité, ale od toho všeho by vás moudrý hosting měl odstínit a prostě to zařídit. Přesto je mnoho hostingů nemoudrých nebo si k certifikátům dávají velkou přirážku, takže zařízení certifikátu může vypadat i takto:

  1. Najdete si certifikační agenturu,
  2. vystavíte si u ní certifikát. Zaplatíte pár stovek, certifikát přijde mailem v příloze. Je to dlouhý text ve tvaru rozsypaného čaje. (Jde v podstatě o privátní klíč.) Čitelné jsou v něm jen poznámky na začátku a na konci.
  3. V rozhraní hostingu najdete příslušný chlívek a ten dlouhý text s privátním klíčem certifikátu tam nakopírujete. Kliknete na potvrzení a když máte štěstí, tak to funguje.
  4. Mnoho hostingů možnost vložení vlastního certifikátu v administraci nemá. V takovém případě se obvykle certifikát posílá mailem administrátorovi serveru, který ho tam někam nakopíruje ručně.
  5. Podle toho, na jakou dobu je certifikát vystavený, se to musí pravidelně opakovat, obvykle jednou ročně nebo po třech měsících.
  6. A vymýšlejí si za to různé poplatky.

Což je třeba pro mě dost pracná hrůza. V takových případech bych rovnou uvažoval o změně hostingu.

Přirážky k ceně

Mnohé hostingy se vám budou snažit vysvětlit, že jim máte za provoz na https platit víc peněz než za http. Hlavní záminky jsou tyto:

Vedle serverů vyžadujících platbu ale už dnes (psáno 2016 a 2017) existuje několik hostingů, které SSL nebo TLS certifikát od Let's Encrypt nastavují zcela automaticky a zadarmo. Abych je proslavil, udělal jsem si katalogovou stránku, ze které odkazuji na všechny hostingy, které umožňují provoz https zadarmo (nebo opravdu velmi levně).

Certifikáty pro subdomény a Wildcard

Když to zjednoduším, existují dva základní typy certifikátů:

  1. základní certifikát pro jednu doménu nebo subdoménu (přesněji pro jedno hostname)
  2. tak zvaný Wildcard certifikát pro všechny subdomény na dané L2 doméně (značí se hvězdičkou před jménem domény)

Základní certifikáty potřebujete pro každou subdoménu svého webu. Pokud například vlastníte doménu example.com a máte na ní subdomény blog a shop, potřebujete v praxi 4 základní certifikáty:

  1. certifikát pro example.com
  2. certifikát pro www.example.com
  3. certifikát pro blog.example.com
  4. a certifikát pro shop.example.com

Jak jistě vidíte, v případě rozsáhlejších webů to může být složité, takže se vyplatí pořídit si wildcard certifikát, který pokryje všechny subdomény, které na dané doméně provozujete. Ve výše zmíněném případu by to byl jeden certifikát:

  1. wildcard certifikát pro *.example.com

Wildcard certifikáty jsou v praxi přibližně 5x dražší než placené certifikáty základní (takže stojí tisícovky ročně). Jejich velká nevýhoda je, že sice podporuje subdomény, ale už ne subdomény subdomén (tedy subdomény 4. řádu).

Bezplatné certifikáty zatím vydává pouze Let's Encrypt. I když Let's Encrypt už umí vydávat wildcard certifikáty, ne každý hosting jeho wildcard umí použít. Z toho plyne, že při pořizování bezplatných certifikátů je obvykle nutno pečlivě se rozvzpomenout, na jakých subdoménách něco běží a pro všechny ty subdomény si vyžádat certifikát (ať už mailem nebo v admin rozhraní hostingu).

Kromě wildcard certifikátů ještě existují i multidoménové, které umí zabezpečit více domén najednou. Některé hostingy takový multidoménový certifikát vystavují v případech, kdy má doména více subdomén. Jiné hostingy si vždy pro subdoménu žádají o nový certifikát.

Nastavení subdomény cluetrain.rovnou.cz s možností snadného zapnutí letsencrypt

Výřez screenshotu z hostingu C4, který má https a certifikáty pro subdomény dotaženy do dokonalosti.

Ověření bezpečnosti SSL

Na webu https://www.ssllabs.com/ssltest/ se zadá doména a nechá se spočítat skóre, jak moc je SSL nebo TLS skutečně zabezpečené. Jde o různé nainstalované protokoly, sílu šifrování a podobně. Moc tomu nerozumím, ale pochopil jsem, že skóre horší než C je dobré omlátit poskytovateli hostingu o hlavu a chtít nápravu.

Chyba zvaná smíšený obsah

Poté, co máte na serveru nastaven certifikát, můžete zkusit poprvé své stránky pustit na https. To se udělá normálně tak, že do prohlížeče napíšete adresu svých stránek a pouze nahradíte v adrese http:// za https://.

Pokud je na serveru všechno vyřešené, měla by se stránka normálně zobrazit. Velmi často ale i potom zobrazí vedle adresy hlášení, že připojení není zabezpečené. Je to tím, že stránka obsahuje nějaké prvky načítané přes nezabezpečené http. Anglicky se to označuje jako mixed content, což překládám jako smíšený obsah. Myslí se tím, že se míchají protokoly.

V různých prohlížečích to pak vypadá různě, ale je to s obměnami totéž: https nějak funguje, ale hlásí, že není plně zabezpečené.

kompromitované https ve Chrome

Takhle vypadá chyba v Chrome (zvýraznění a popisky jsou moje úprava). Do stránky jsem úmyslně vložil obrázek přes http a prohlížeč už hlásí, že "připojení není plně zabezpečeno". Obrázek je pasivní obsah, takže to ještě neřve tolik. Takhle vypadá stejné hlášení ve Firefoxu:

kompromitované https ve Firefoxu

Obecně platí toto pravidlo:

Pokud je stránka na https, smí používat také jenom prvky, které jsou na https. Je jedno, jestli z vlastního serveru nebo z jiného. Musí to ale běžet na https a nikde nesmí být použit protokol http.

Krátké vysvětlení, proč není bezpečné načítat do https tránek http objekty. Https se používá hlavně kvůli tomu, aby nikdo cestou po síti neviděl, jakou přesnou stránku si uživatel vyžádal. Https protokol je kódovaný, a tak případný útočník (notebook na stejné wifi, operátor, vojenská rozvědka) vidí pouze to, jakého serveru se uživatel ptá. Zbytek komunikace je z pohledu útočníka nesmyslný rozsypaný čaj, což je dobře. Jestliže si stránka vyžádá načtení dalšího objektu, například obrázku, a obrázek je na https, útočník nadále vidí pouze rozsypaný čaj. Kdyby ale obrázek byl na http (na diagramu vpravo červeně), požadavek a odpověď by se odehrály v otevřeném http protokolu, který by útočník viděl. Z různých informací (například když je obrázek vložen jen do jedné stránky) by pak mohl odvodit i to, na jakou konkrétní https stránku (na diagramu vpravo s výstrahou) se uživatel díval. A to je proti principu zabezpečeného připojení. Pokud útočník může uživatelovu aktivitu odhalit z takovýchto triviálních chyb, nemůže se to přece nazývat zabezpečené připojení. Nehledě na to, že takový prvek může útočník podvrhnout.

Co jsou načítané objekty, které nesmí být na http

Obecně cokoli, co je do https stránky načítáno dalším požadavkem. Jedná se o tak zvaný smíšený obsah (mixed content), který se dělí na pasivní smíšený obsah a aktivní smíšený obsah. Pasivní smíšený obsah jsou obrázky a podobné tagy, které se do prohlížeče načtou i na http protokolu a i v případě nejhoršího útoku jenom zobrazí nějakou blbost. Patří mezi ně:

Aktivní smíšený obsah dokáže teoreticky udělat větší paseku, a tak je v moderních prohlížečích dokonce úplně blokován a nenačte se vůbec. Aktivní smíšený obsah je tento:

Co navíc vadí prohlížeči Chrome

V lednu 2017 Chromu vadí i formulář namířený na action, která není na https, tedy

<form action="http://*">

Ostatní prohlížeče se cukají až v případě, že uživatel takový formulář odesílá.

Co naopak nevadí

Nevadí odkazy. <a href="http://cokoliv" > je v pořádku. Dává to smysl, protože při zobrazení stránky se uživateli nenačítají stránky, na které stránka odkazuje. (Nevím, jestli nebudou vadit nějaké atributy na preload, nemám to vyzkoušené.)

Teoreticky by neměly vadit ani formuláře namířené na http, protože ty se spontánně neodesílají, ale jak už jsem uvedl, Chromu vadí.

Jak se zbavit smíšeného obsahu načítaného přes http

2 základní metody jsou tyto:

V praxi doporučuji kombinaci obou přístupů. Většinou začínám testem, jestli stránka na https náhodou nefunguje sama od sebe, což většinou nefunguje. Tak najdu pár chyb, ty ve zdrojácích opravím a když už mám ty zdrojáky otevřené, tak je projedu hledáním řetězce http://.

(Když mě okolnosti donutí řešit to na Windows a nemám Cygwin (a tedy ani grep), pomáhám si programem Notepad ++, který má celkem dobré hledání a nahrazování v celých adresářích.)

Další řešení je hlavička upgrade-insecure-request, viz níže.

Nahrazení http:// za https:// a relativní adresování //*

Pokud ve zdrojáku najdu načítaný objekt ze stejného serveru, který zrovna řeším, tak můžu přepsat http://* adresu (obrázku, skriptu, stylu) prostě na https://* , protože skripty, obrázky a styly už by na stejném serveru přes https měly fungovat. Pokud ještě na https neběží, můžete zatím místo https:// používat "relativní" adresu začínající dvěma lomítky: //*.

<script src="//example.com/skript.js">

Když nevím, jestli web poběží na http, nebo https, je dobré používat tyhle relativní zápisy nezávislé na protokolu.

Ještě připomenu, že podobně se chovají všechny relativní adresy. Ať už ty, které začínají lomítkem (kořenové adresy), nebo ty začínající prostě jménem adresáře nebo souboru. Pro všechny tyto adresy platí, že pokud je volající stránka na https, i volaná stránka bude na https. A vice versa pro http. Máte-li tedy web postavený pečlivě na relativních adresách, přechod na https by měl být hračka.

Dlouhodobě relativní adresy začínající // doporučit ale nelze, protože ve skutečnosti nechcete nechat otevřenou možnost načítat prvky přes staré http. Ve skutečnosti chcete přejít na https, takže byste měli používat adresy s https:// na začátku.

Pamatujte také, že vůbec nevadí, když se https obsah načte do http stránky. V praxi je proto možné měnit protokol u obrázků a skriptů na https i dlouho před přechodem celého webu na https.

Nahrazení http:// za https:// v případě cizích serverů

Záludná situace nastává, když mám do stránky vloženy prvky, které se načítají z jiných serverů, které nemám pod kontrolou. Osobně se snažím takových prvků mít na svých stránkách co nejméně, ale někdy to prostě je potřeba. Jsou to různá počitadla, reklamy, fonty, ikonky, šmírovadla Facebooku tvářící se jako tlačítko like, vložená videa apod. Takové prvky musejí být taky na https, jenomže ne vždycky to jde zařídit.

  1. Nejjednodušší je zkusit, jestli náhodou nefungují na https. Prostě přepsat http:// za https:// (nebo rovnou za //) a vyzkoušet, jestli to funguje. Překvapivě často je všechno v pořádku. Hlavně velké servery od roku 2016 už všechno jedou na https. Reklamní servery už to taky musely pochopit.
  2. Když to nefunguje, je dobré se zeptat provozovatele toho cizího serveru, jestli poskytuje https verzi. Třeba ho vůbec nenapadlo, že by to někdo mohl potřebovat. Https prostě zapne nebo to zařídí jinak.
  3. Drobný statický obsah z cizích serverů se dá nakopírovat k sobě a vydávat ho na https od sebe. Samozřejmě je přitom potřeba neporušovat autorská práva.
  4. Když ty http prvky nejsou moc důležité, tak je často ze stránky prostě smažu. Nazdar.
  5. Pokud něco naopak důležité je a provozovatel cizího serveru se na https netváří, dá se obsah z cizího serveru proxovat přes vlastní server. Prohlížeč si potom myslí, že obsah přišel z mého serveru, je to na https, takže všechno v pohodě. Já proxuji pomocí mod_rewrite, ale dá se to používat jenom při rozumně malé návštěvnosti.
  6. Poslední možnost je tento problém ignorovat a ve starých stránkách nechat nezabezpečené prvky, zejména obrázky. Uživatelé se na stránky dostanou, prohlížeč může "blikat". V případě javascriptů na http, které budou blokovány, se stránka může rozpadnout, ale to je tak všechno. Osobně ignorování tohoto problému nedoporučuji, ale v některých situacích jsem schopen ho pochopit. Například staré blogy se spoustou externích obrázků je lepší nechat běžet, než se snažit opravovat. Také neumím nijak řešit problematiku diskusí, do kterých se dají vkládat externí obrázky. Přijde mi lepší nechat https rozbité pasivním smíšeným obsahem, než uživatelům vkládání a prohlížení obrázků znemožnit.

Upgrade insecure request

Také bych měl zmínit, že existuje http hlavička

Content-Security-Policy: upgrade-insecure-request

a případně její meta verze

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Potom vždy, když prohlížeč ve zdrojáku najde http: prvek, zkusí ho načíst s https: na začátku. Dnešní prohlížeče to podporují, ale záludnost je myslím zřejmá: pokud server, ze kterého se prvek načítá, nepodporuje https, tak se prvek vůbec nenačte. Naopak když jsem si jistý, že všechny servery, ze kterých se prvky načítají, https zvládnou (s jinak stejnou adresou), můžu upgrade-insecure-request bez obav použít. Pak vůbec nemusím http: prvky v kódu nahrazovat (což ale i tak doporučuji udělat).

Od roku 2021 bude další možnost, a totiž mixed content ignorovat a nechat to vyřešit prohlížeč. Některé prohlížeče (např. Chrome od verze 86) se všechny objekty načítané přes nezabezpečené http povýšit na https, jako kdyby byla hlavička upgrade-insecure-request přítomná. Takže se serveru místo na http zeptá rovnou na https. To je trochu riskantní, pokud obrázky a jiné objekty načítám ze serveru, na kterém https neběží. V praxi se to tedy bude týkat hlavně obrázků vložených z cizích neudržovaných serverů, což ale byla problematická praktika vždycky.

Hromadná kontrola stránek

Procházet jednu stránku po druhé a kontrolovat, jestli prohlížeč neobsahuje problémy, je dost zdlouhavá práce.

Našel jsem nástroj SSL Check, který si umí projít 200 stránek z webu a zkontrolovat https na nich. 200 stránek je nepříjemné omezení, ale většinou je to dobrý vzorek a najdou se tak hlavní chyby, kterými trpí některé části webu.

Desktopová (počítačová) aplikace HTTPS Checker umí projít 500 stránek webu (do března 2017 uměla pouze 100). Načítá je z mého počítače a reportuje problémy. Při instalaci sice hází nějaké chyby a je to jenom omezená verze, ale leccos umí i bez placení. Kromě smíšeného obsahu umí reportovat i interní odkazy vedoucí na staré http. Omezení na 500 stránek obcházím tím, že pokaždé zadám jinou podstránku, takže většinu chyb takhle najdu.

Jarda Hlavinka používá Screaming frog. "Jde pustit crawlera na testovací web a pak až projde všechny URL, tak si vyexportuješ seznam insecured content + URL, kde se tak děje."

Pokud znáte další nástroje, dejte mi prosím vědět.

Po spuštění se pro kontrolu, jestli na stránce není mixed content, dá použít i hlavička Content Security Policy. CSP je sada http hlaviček, která omezuje načítání prvků z různých (hlavně cizích) zdrojů do stránky. Dá se ale použít i na to, aby prohlížeče, když načtou smíšený obsah, reportovaly autorovi webu, kde se na stránkách ten smíšený obsah nachází. Osobně jsem to nezkoušel, ale dělá se to prý touto hlavičkou:

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/hlaseni.php

přičemž na /hlaseni.php je dobré rozběhnout nějaký skript, který ta hlášení bude někam ukládat, abyste si je potom mohli přečíst a chyby opravit.

Přesměrování z http na https

Poslední důležitý krok při přechodu z http na https je nastavení přesměrování.

Pokud postupujete podle tohoto návodu, dostali jste se do stavu, kdy se na http a na https vyskytuje tentýž obsah. Většina serverů funguje po zapnutí https právě takhle -- stejný obsah poskytují na http i na https. Teoreticky není problém poskytovat dlouhodobě stránky na obou protokolech. V praxi to ale může způsobovat problémy zejména vyhledávačům, a tak pokud všechno na https funguje, doporučuji vždycky na https přesměrovávat.

Přesměrování je potřeba udělat na straně serveru http hlavičkou číslo 301. Také je nutné přesměrovávat jedna ku jedné, totiž každou http adresu přesměrovat na úplně stejnou URL, ale s https na začátku.

Jsou různé způsoby, jak udělat na serveru přesměrování. Já používám mod_rewrite a jeho instrukce zapisuji do souboru .htaccess. Postupem času jsem si vyladil co nejobecnější zápis:

# presmerovani z http na https
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301]

Co to dělá: zapíná mod_rewrite. Potom testuje, že volané URL není na https (to je to %{HTTPS} off), což zmamená, že požadavek míří na http. To nechceme. V takovém případě se libovolný požadavek (.*) přesměruje na https://, za které se vyskládá celá požadovaná adresa. Přesměrování je trvalé, a tak má http kód 301. Prohlížeč novou adresu s https vezme, zeptá se na ni a dostane obsah.

Funguje mi to všude kromě hostinu Endora, tam používám řádek pro RewriteCond jiný. Třeba se vám bude hodit i na jiných hostinzích:

# specialita pro Endoru, která neumí %{HTTPS}
RewriteCond %{HTTP:X-Forwarded-Proto} !^https$

Další možný zápis podmínky kontroluje, zda server komunikuje na portu 80, což je port pro nezabezpečené http. Měl by fungovat stejně jako %{HTTPS} off:

RewriteCond %{SERVER_PORT} 80

Na hostingu Onebit mi funguje pouze tento zápis:

RewriteCond %{ENV:HTTPS} !^.*on

Některé hostingy pro přesměrování vyžadují, aby byla nastavena RewriteBase na root:

RewriteBase /

Když už popisuji speciality různých hostingů, tak C4 umí přesměrování z http na https nastavit na jedno kliknutí v adminu. Možná to umí i jiné hostingy, nevím.

Proč neprovozovat zároveň http a https

Kromě bezpečnosti komunikace a ochrany soukromí uživatelů jsou hlavním důvodem vyhledávače. Nechci bezpečnost nebo soukromí podceňovat, ale vyhledávačům rozumím přeci jen řádově lépe. Jde o to, že vyhledávač rozlišuje dvě URL http://example.com/ a https://example.com/ jako dvě různé adresy. Je to rozumné, protože na těchto dvou adresách může být principiálně zcela odlišný obsah. Jasně, většinou je na nich zcela totožný obsah, ale může být odlišný a vyhledávač na takovou situaci musí být připravený. Takže tyto dvě adresy rozlišuje jako dvě různé entity.

Pokud si někdo udělá web a provozuje ho zároveň na http i na https, tak se mu může stát, že vyhledávač najde část jeho webu na http a část na https. Jednu a u samou stránku najde na http a za chvíli na https. Jasně, může se stát, že obě adresy správně kanonizuje do jedné entity, ale podařit se to také nemusí. V takovém případě je na obou URL stejný obsah, ale část zpětných odkazů vede na verzi s http, jiná část na verzi s https. Takže se tříští ranky a autorita stránky mezi dvě URL. Když se dva perou, třetí se směje. Tím třetím je v tomto případě konkurence. Takovouto http/https nesjednocenou stránku ve vyhledávači snáze předběhnou konkurenční stránky.

Https na Seznam.cz je v pohodě

Před rokem 2016 mohla být změna protokolu na https provázena významným poklesem pozic. Nestávalo se to všem, ale dělo se to. Od ledna 2016 je ve fulltextu Seznamu nasazeno řešení, které všechny ranky zachovává. Funguje obzvláště dobře, pokud se při přesměrování mění pouze protokol a cesty jsou zachovány tak, jak byly. Příklady zápisů mod_rewrite, které v tomto návodu uvádím, jsou přesně tohoto druhu = zachovávají cestu a mění pouze protokol. Odzkoušel jsem si to na spoustě svých webů. Paradoxně největší pokles ve vyhledávačích jsem při přechodu na https zaznamenal u tohoto webu (jakpsatweb.cz) na Google.

Přechod na https v redakčních systémech

Kdo pro správu stránek používá redakční systém, měl by zkusit využít nějaké doplňky, které jsou na přechod na https přímo určeny. Například u Wordpressu vypadá přechod takto:

  1. na straně hostingu se nastaví certifikáty,
  2. do Wordpressu se nainstaluje doplněk Really Simple SSL a zapne se,
  3. v konfiguraci se změní hlavní adresa webu z http na https.
  4. Pak se kouká, jak to běží nebo co to dělá za chyby.

Podobný proces očekávám i v jiných redakčních systémech než je Wordpress, ale nemám přímou zkušenost.

Co udělat po migraci na https

Skoro se mi chce říct, že nemusíte dělat nic. Pokud jsou totiž správně certifikáty, je odstraněn smíšený obsah a nastaveno správné přesměrování, všechno by mělo tak nějak fungovat. Proberu, co je možné zvážit.

Namířit odkazy na https verzi

U správně udělaných webů by se všechny interní odkazy měly přehodit samy na https verzi. Ale i tak zbudou zejména externí zpětné odkazy, které dál míří na http. Není špatný nápad je postupně předělávat na https. Dvě poznámky:

Sledujte návštěvnost

Při přechodu na https se nedá vyloučit nějaká chyba, kterou není snadné odhalit. Uživatelům ale může znepříjemnit nebo znemožnit vstup na web. Takovou chybu je potřeba včas objevit. Ideální jsou na to různá počitadla (Google Analytics, Toplist). Jistý drobný a dočasný pokles návštěvnosti je běžný u návštěvnosti z vyhledávače, řekněme na o čtvrtinu na pár dnů až týdnů. Pokud ale návštěvnost spadne o vyšší desítky procent, může to třeba znamenat problém s podporou nějakého prohlížeče nebo chybu na straně hostingu.

Vyhledávačům může trvat delší dobu, než začnou odkazovat na https verzi. Nemělo by to ničemu vadit, protože přes přesměrování se uživatelé dostanou na správnou verzi. Podle mých zkušeností Googlu trvá změna odkazování na https průměrně 2 týdny, Seznamu něco kolem dvou měsíců. Interně by měly obě adresy kanonizovat, takže by se žádná popularita ztratit neměla. Těžko ale soudit, jestil to tak skutečně je, protože svoje weby jsem na https převáděl vždycky, když nebyla sezóna, takže pokles návštěvnosti úplně není s čím srovnávat.

Zkontrolujte robots.txt a sitemapy

Občas jsem viděl v případě velkých webů, že přes robots.txt zakázali přístupy robotům na https verzi, dokud ji nebudou mít hotovou. Pak přešli na https úplně a z robots.txt ten zákaz https zapomněli odstranit.

Pamatujte, že soubory

jsou pro vyhledávač dva různé soubory. Pokud chcete robotům dát různé instrukce pro různé protokoly, napište instrukce pro http verzi do souboru na http a naopak.

Sitemapy jsou soubory sloužící pro vyhledávače, aby rychleji objevily obsah, zejména pokud je ho mnoho. Kdo změní adresy z http na https, měl by to promítnout i do sitemapy. Podobně i do RSS kanálů a dalších zdrojů, kterými můžou získávat adresy další automaty.

Přehoďte na https kanonické linky

Pokud používáte kanonické linky, je životně důležité přehodit je na správnou URL, v tomto případě tedy na https.

<link rel="canonical" href="https://example.com/url.html">

Pokud necháte kanonické linky mířit na http verzi, je to v háji, protože to vyhledávač úplně zmate. Lepší by bylo pak kanonické linky vůbec nemít.

Založit novou property v Search Console

Kdo používá Google Search Console -- dříve Google Webmater Tools -- nebude moc potěšen, protože musí každý web založit znovu pro https protokol a nechat ověřit. Škoda, že přestanou navazovat statistiky.

Zdokumentovat hacky

Jestli jste při migraci použili nějaké nestandardní kroky, zapište si to. Může to po vás někdo muset předělávat nebo (a to je častější) to budete muset pochopit po sobě, až se k tomu dostanete za pár měsíců.

Oželet lajky z Facebooku

Facebook počítá lajky pro stránku podle URL. Když se změní URL, přijdu o všechny lajky a facebookové diskuse. Existují dvě šílená řešení.

Lajky oželte.

Ještě vyšší bezpečnost

Chtěl jsem tenhle návod psát pro amatéry, takže už jenom heslovitě:

Kromě toho https je nutnou podmínkou pro přechod na HTTP 2.0, které je úžasňoučké, například protože umožňuje server push, tedy přednačítání skriptů a stylů. Až si o HTTP 2.0 něco najdete, tak po něm budete toužit, takže je dobré mít https.

 

Publikováno 9. února 2017, aktualizováno v červnu 2019.

 

Reklama

www.webhosting-c4.cz, extra rychlý SSD webhosting s doménou v ceně
o tvorbě, údržbě a zlepšování internetových stránek

Návody HTML CSS JavaScript Články Ostatní

Základy Prvky stránek Tvorba webu

Jak psát web píše Yuhů, Dušan Janovský. Kontakt.