HTTPS a WordPress – podrobný průvodce

Od Chrome 68 jsou všechny weby, které nepoužívají šifrovaný protokol, označovány jako nezabezpečené. Od září 2018 je toto označení ještě mnohem výraznější. Pokud tedy šifrovaný protokol zatím nepoužíváte, měli byste to co nejrychleji napravit a přejít na HTTPS.

Tento vyčerpávající a podrobný článek se snaží na jednom místě obsáhnout všechny podstatné informace, které se týkají problematiky HTTPS a WordPress. Nepředkládá pouze body, které je potřeba vykonat, ale snaží se i vysvětlit proč, občas proto zabíhá i do techničtějších pasáží, nebo alespoň odkazuje na další zdroje. Najdete zde:

• trošku teorie o zabezpečených protokolech,
• důvody pro používání HTTPS,
• jak vybrat vhodný certifikát pro váš web,
• zda je Let’s Encrypt dostatečný,
• kde nakupovat SSL certifikáty,
• jak vygenerovat privátní klíč a CSR + k tomu pomocné nástroje,
• nastavení pro WordPress, jak nahradit stará URL za nová a jak provést přesměrování v htaccess,
• nahrazovat URL budeme pomocí pluginu Better Search Replace, pomocí WP-CLI i nevhodně pomocí SQL dotazu,
• řešení běžných problémů, jako je smíšený obsah (i v JSON u pluginů jako je TablePress) nebo smyčka přesměrování,
• krátké info o dalším využití různých typů certifikátů – podepisování dokumentů, mailů, aplikací, VPN, RDP,
• a na konec rychlý souhrn jednotlivých kroků.

Co je HTTPS?

HTTPS je webový komunikační protokol, který neposílá data v čitelné podobě, ale šifrovaně (HTTP Secure). Zajišťuje tak, že data po cestě nelze odposlechnout a identifikuje server, se kterým komunikujete. Nešifrované HTTP komunikuje typicky po TCP portu 80, HTTPS využívá port 443.

K zabezpečení využívá protokol TLS (dříve se používal protokol SSL, který je dnes již velmi zastaralý, samotná zkratka se však dále používá). Ten používá asymetrické šifrování (pro šifrování a dešifrování je použit jiný klíč – privátní a veřejný) pro ověření identity a domluvy symetrické šifry (jeden klíč na zašifrování i rozšifrování) pro přenos dat – kvalita domluvené šifry je zásadní k zajištění bezpečnosti přenosu.

Nejrozšířenější verzí TLS je 1.2 (podpora verze 1.0 a 1.1 končí v březnu 2020 a lze tak počítat, že prohlížeče začnou weby, které jej využívají, označovat za nedůvěryhodné). Aktuální verzí je 1.3 a přináší mnoho benefitů především v oblasti výkonu, starší prohlížeče a IE však podporu nemají. TLS 1.2 podporuje naprostá většina používaných prohlížečů, v Internet Explorer 8 – 10 se však musí explicitně povolit.

Webový server klientovi posílá svůj veřejný klíč ve formě certifikátu, který byl společně s dalšími údaji (konkrétně například doménou webu a dobou platnosti) ověřen důvěryhodnou certifikační autoritou. Veřejným klíčem může pak klient data zašifrovat tak, že je bude možné dešifrovat pouze se znalostí privátního klíče.

Aby vše fungovalo, potřebujeme tedy certifikát – SSL certifikát (technicky se jedná o certifikát X.509 s rozšířením pro identifikaci serveru – 1.3.6.1.5.5.7.3.1) ověřený certifikační autoritou, které důvěřuje váš prohlížeč či operační systém. Pro interní použití si můžete vytvořit i vlastní certifikační autoritu, kterou nainstalujete do svých zařízení, aby jí důvěřovaly. Důvěřovat můžete dokonce i konkrétnímu jednomu certifikátu, který si vygenerujete – pak se jedná o Self-Signed certifikát. Mějte na paměti, že tyto certifikáty lze používat pouze na zařízeních, nad kterými máte kontrolu, jinak prohlížeče zobrazí bezpečnostní varování – i tak ale bude komunikace šifrovaná stejným způsobem, jako byste měli certifikát od komerční autority.

Je třeba zmínit, že použití HTTPS se nerovná anonymizaci. Pokud jste v minulosti chtěli používat HTTPS, musela mít vaše doména i vlastní IP adresu, kde běžela jen ona. To proto, že byla šifrována též informace, s jakou doménou komunikujete. IP adres je však omezené množství, a tak bylo potřeba vymyslet jejich sdílení – k tomu se do protokolu vytvořilo rozšíření SNI, kdy do nešifrované části byla přidána i informace o tom, pro jakou doménu je provoz určen. I přes použití HTTPS lze tak například blokovat určité domény a prakticky každý po cestě může vidět, na jaké weby zrovna přistupujete – lze však poznat pouze doménu a ne konkrétní podstránky nebo číst přenášená data. SNI není podporováno v prohlížečích Internet Explorer ve Windows XP (tuto kombinaci snad již nikdo nepoužívá – https://caniuse.com/#feat=sni).

Ukázkovou konfiguraci pro váš server si můžete nechat vygenerovat (pro Apache, Nginx a další otevřené webservery) podle toho, jak moderní prohlížeče chcete podporovat.

Ve vygenerované konfiguraci si můžete všimnout dlouhého řetězce podporovaných kombinací šifrování a ověřování – tzv. Cipher Suite. Ty jsou seřazeny podle priority (od nejbezpečnějších) a server se s klientem domluví na první, kterou mají společnou. Kombinace vypadá typicky nějak takto:

Šifrování založené na AES256 poskytuje velmi dobré zabezpečení. V případě TLS1.3 je situace jednodušší, je vybráno pouze několik silných kombinací, které obě strany musí podporovat – odpadá tak složité vyjednávání a nemůže se stát, že se domluví komunikace se slabší šifrou, než je nutné. Pokud vás toto téma hlouběji zajímá, můžete se podívat, jak TLS komunikace probíhá na úrovni jednotlivých bytů.

Můžeme se setkat s 2 typy klíčů – starší RSA (podle autorů Rivest, Shamir, Adleman) a modernější ECDSA (Elliptic Curve Digital Signature Algorithm). ECDSA poskytuje stejně bezpečný klíč jako RSA při mnohem menší velikosti klíče a je tak rychlejší. Není však podporován staršími systémy (opět Windows XP).

Pokud chcete nastavit HTTPS na IIS běžícím na Windows Serveru, je třeba certifikát s privátním klíčem (soubor s koncovkou PFX nebo P12) nainstalovat do úložiště certifikátů systému a následně jej zvolit v nastavení IIS. Můžete také použít nástroj pro správu certifikátu od certifikační autority DigiCert a postupovat podle jejich kompletního návodu nastavení IIS (část s nastavením IIS je shodná pro oba postupy).

Proč používat HTTPS?

Používání HTTPS by mělo být samozřejmostí a slušností. Pokud ale i přesto potřebujete některé důvody, tak tady jsou:

• Veškerá data jsou přenášena bezpečně a není je možné dostupnými prostředky odposlechnout a modifikovat. Velké nebezpečí zde představují nezabezpečené routery ve vaší domácí síti i v dalších sítích po cestě. Bezpečnostních chyb v routerech je opravdu mnoho a často se zapomíná na jejich pravidelnou aktualizaci. Útočník pak oběti modifikuje navštěvované HTTP stránky a vkládá do nich své reklamy, malware, skripty na těžení kryptoměn v prohlížeči návštěvníka, nebo útočí na další stránky. Více info naleznete v sekci o útocích na HTTP.
• Můžete použít moderní a rychlý protokol HTTP/2, který umí podstatně zrychlit načítání zdrojů. Navíc lze také použít TLS 1.3, díky kterému se zrychlí i samotná inicializace spojení.
• Z marketingového pohledu je HTTPS podmínkou pro použití Google Merchant Center a dalších služeb.

A jaké jsou nevýhody? O žádných zásadních nevím. Zvýšení zátěže serveru kvůli šifrování není dnes nijak podstatné. Při přechodu na HTTPS se můžete setkat s vynulováním počtu Like u FB tlačítka, protože se z pohledu Facebooku jedná o nový web. Jsou postupy, jak to částečně řešit, ale do budoucna přinášejí problémy, a je tedy lepší na to nehledět a zamyslet se, zda vám i vašim návštěvníkům Like tlačítka vůbec přináší nějakou přidanou hodnotu.

Pokud používáte pro komentáře službu Disqus, budete muset pro zachování komentářů použít jejich migrační nástroj.

Reálné útoky na HTTP provoz

Internetové protokoly vznikly v době, kdy sítě byly převážně akademické a příliš se nepočítalo s jejich zneužíváním. S rostoucím výkonem HW a rozšířeností internetu tak vzrůstají i možnosti a četnost rozličných útoků využívajících právě nedostatky starých protokolů jako je HTTP, FTP, DNS nebo třeba routovacího protokolu BGP, používaného pro směrování provozu mezi velkými sítěmi.

Nešifrovaný provoz je snadno čitelný a modifikovatelný. Vlastník sítě, kterou prochází, si s ním tak může dělat prakticky cokoliv – od čtení hesel a přihlašovacích cookies, po vkládání škodlivého obsahu. Předpokladem pro úspěšný útok je potřeba, aby provoz procházel přes síťový prvek kontrolovaný útočníkem. To se může zdát jako těžko splnitelné, v globálním měřítku však k podobným útokům dochází až nebezpečně často. Problém však není jen v samotných neaktualizovaných děravých routerech, kterých je opravdu velké množství, ale i ve skutečnosti, že pokud vlastníte dostatečně velkou a výkonnou síť, můžete okolní sítě donutit posílat svůj provoz přes ní. Jeden z typů těchto útoků se nazývá BGP hijacking.

Lze tak přesměrovat provoz i celých států. Použití těchto technik můžeme vidět například v uniklých dokumentech NSA, kdy došlo k přesměrování provozu celého Jemenu. Několikrát ročně se odhalí podobné útoky vedené často z Číny, Ruska i menších zemí, kdy může dojít k přesměrování značné části světového internetového provozu skrze nedůvěryhodné sítě. Čínské útoky bývají vedené například proti GitHubu, protože na něm lze nalézt mnoho nástrojů pro překonávání cenzury tamního internetového prostředí. Při podobných útocích byl například návštěvníkům HTTP webů z celého světa vkládán do stránek skript provádějící DDoS útok na daný cíl. Úspěšně provedeným útokům se však nevyhnuly ani různé platební brány, služba Amazon AWS, nebo veřejné DNS Google. Mezi velké útoky z poslední doby se řadí například přesměrování více než 200 sítí ruským operátorem Rostelecom (postiženy byly například Google, Amazon, Facebook, Akamai, Cloudflare, GoDaddy, Digital Ocean, Hetzner, nebo Linode).

S podobnými modifikacemi provozu se však můžeme potkat i u nás. V roce 2018 například operátor O2 přesměrovával HTTP provoz uživatelů na svůj portál pro „souhlas s GDPR“.

Nasazení HTTPS je tak jedním z prostředků, jak omezit zneužívání prohlížečů návštěvníků vašeho webu k nekalým aktivitám všemožných subjektů, přes které jejich provoz prochází.

HTTP/2

Nová verze protokolu HTTP s sebou přináší především zlepšení výkonu. Je toho dosaženo především díky možnosti stahovat paralelně více zdrojů najednou tzv. multiplexing – dříve prohlížeče stahovaly typicky maximálně 6 zdrojů najednou. Výkon se tak nejvíce projeví na webech, které stahují větší množství zdrojů – typicky například eshopy, kde se stahuje mnoho náhledů produktu v kategoriích. V případě, že váš web používá dynamicky generované obrázky, to může mít nepříznivý dopad na server, který může být velkým počtem souběžných požadavků přetěžován. Není to však problém HTTP/2, ale aplikace samotné a je tak vhodné se zamyslet nad úpravou tohoto chování a využití nějaké formy cachování již vytvořených zdrojů, ať už lokálně nebo v CDN.

To však není jediný trik, protokol je binární = strojům se lépe čte, jsou zde zkomprimované hlavičky (což například u cookies může ušetřit poměrně hodně dat stahovaných s každým požadavkem). Další funkcí je tzv. Server Push, to je technika, kdy webový server (musí pro to mít podporu) pošle některé zdroje ještě před tím, než si o ně prohlížeč řekne a až na ně dojde, jsou již připravené.

Server Push se aktivuje přidáním HTTP hlavičky Link s parametrem rel=preload (například v .htaccess). Existují pluginy, které tuto hlavičku automaticky přidají, je však ale lepší se jí věnovat individuálně pro každou stránku, protože automatické pushování všech zdrojů může způsobit zbytečné posílání mnoha dat, které prohlížeč stejně nakonec odmítne. Více info o server push.

Pro použití protokolu HTTP/2 jsou potřeba následující podmínky:

• musí být podpora ze strany hostingu (webserveru)
• web musí být na HTTPS (norma povoluje využití i na nešifrovaném protokolu, ale tvůrci prohlížečů se jej rozhodli podporovat pouze šifrovaně)

Pokud máte možnost použít HTTP/2, určitě ji využijte. Zda váš web podporuje HTTP/2 můžete otestovat online.

Postupně se začíná v produkci objevovat i další nový protokol HTTP/3. Ten je založen na protokolu QUIC od Google a využívá rychlejší transportní protokol založený na UDP (spolehlivost přenosu neřeší síť, ale až vyšší protokoly). Díky tomu se například zrychlí navazovaání spojení. Komplexní informace v angličtině naleznete například na https://http3-explained.haxx.se/en.

Zabezpečí SSL certifikát můj web?

SSL certifikát pouze garantuje, že komunikujete s vlastníkem privátního klíče a komunikace nebyla nijak pozměněna ani odposlechnuta. Zabezpečení webu je nutné řešit bez ohledu na HTTPS.

Vždy je třeba dbát na:

• Používání silných hesel. Ideálně řešit i omezování jejich hádání.
• Pravidelné aktualizace a zálohování.
• Používání pluginů a šablon z důvěryhodných zdrojů.
• Neponechávání různých testovacích souborů na webu.
• Neprovozování více webů v jednom společném prostoru.
• V ideálním případě blokovat známé útoky.

Typy SSL certifikátů

Certifikáty pro webové stránky se liší v několika ohledech. První rozdělení je podle toho, jaké údaje jsou certifikovány.

Certifikáty podle typu ověření

DV – Domain Validation – certifikátem se garantuje pouze doména, pro získání tohoto typu certifikátu musíte prokázat vlastnictví domény – většinou zasláním e-mailu na adresu webmaster/hostmaster/postmaster/admin/administrator@domena, umístěním ověřovacího souboru na web, nebo vytvoření speciálního DNS záznamu. Tento typ certifikátu je nejpoužívanější, nejlevnější a nejrychleji vystavený. Ověřuje však pouze fakt, že kdo o něj požádal má přístup k doméně a může to být kdokoliv.

OV – Organization Validation – v tomto případě se do certifikátu přidává i jméno organizace, a je tak jistota, že certifikát opravdu patří dané existující společnosti. U ověření společnosti je typicky potřeba shoda jména s údaji vlastníka domény, kontrola s obchodním rejstříkem a telefonické ověření žadatele – telefon je získáván z veřejných telefonních databází zlatestranky.cz nebo 1188.cz. Provedení těchto kroků může trvat několik dní a certifikát je samozřejmě dražší. Informaci o společnosti si může návštěvník webu nechat zobrazit v detailech certifikátu (vlastnost O), na první pohled rozdíl mezi DV a OV certifikátem neuvidí. Speciální certifikáty typu OV se často používají k podepisování aplikací.

EV – Extended Validation – v tomto případě opět dochází k ověření společnosti, které je však podrobnější – kontroluje se například vztah žadatele ke společnosti. Odměnou za tento komplikovanější proces a opět vyšší cenu vám bude v některých prohlížečích „zelený adresní řádek“, ve kterém je vidět na první pohled jméno společnosti. Tento typ certifikátu je výhodný především pokud má vaše firma několik značek a chcete, aby bylo jasné, že patří pod vás. Důležité jsou v oborech, kde je vyšší hrozba phishingu (především na zaměstnace, kteří ví, že by měl být název firmy viditelný). Pokud je však vaší hlavní motivací mít zelený řádek, uvědomte si, že na řadě prohlížečů není pro běžné uživatele rozpoznatelný od běžného DV certifikátu. Tento trend se nejprve objevil u mobilních prohlížečů a s Chrome 77 a Firefox 70 pronikl i k běžným desktopovým prohlížečům. Při zvažování nákupu EV certifikátu byste si měli ujasnit přesné důvody, proč ho chcete – pro většinu webů je spíše zbytečný.

Telefonické ověření většinou probíhá pomocí automatu, který vám nadiktuje několik číslic pro ověření. Telefonát lze často naplánovat přes formulář, který vám autorita zašle, a lze si vybrat z několika světových jazyků. Certifikáty s ověřením společnosti může získat i OSVČ, ale proces bude komplikovanější a bude vyžadovat i úředně ověřený podpis.

Certifikáty podle počtu domén

Dalším typem rozdělení je podle počtu domén, které podepisují.

Certifikáty pro jednu doménu

Jedná se o nejlevnější variantu. Pokud si certifikujete doménu druhého řádu (naswp.cz), typicky k ní získáte i ověření tvaru s www (www.naswp.cz), nepotřebujete tedy 2 certifikáty. U tohoto kroku je dobré si přečíst pokyny registrátora, někteří mohou mít postup obrácený – registrujete certifikát pro doménu s www a ten bude platný i pro doménu bez www.

Certifikáty pro více domén – multidoménové

Pokud máte více různých domén (naswp.cz, wordcamppraha.cz) nebo subdomén, můžete všechny zahrnout pod jeden certifikát – říká se tomu SAN rozšíření (Subject Alternative Name) a platí se obvykle základní certifikát + počet doplněných domén. Jedním certifikátem tak můžete typicky podepsat až 250 různých domén. Domény není potřeba certifikovat najednou a je možné je postupně přidávat.

Certifikát pro všechny subdomény – wildcard

Můžete si také pořídit certifikát ke všem subdoménám *.naswp.cz. Tento certifikát bude platný pro všechny subdomény, které si v budoucnu vytvoříte. S tímto certifikátem budete mít méně práce, nicméně je zde riziko, že někdo nekontrolovaně na vašem serveru spustí vámi certifikovaný web. Z tohoto důvodu nelze získat wildcard EV certifikát. Pokud chcete certifikát pro službu mimo web, je potřeba zkontrolovat, že wildcard podporuje – většina služeb vyžaduje, aby byly v certifikátu domény jasně vyjmenované. Wildcard certifikát lze vystavit i pro Let’s Encrypt, je však třeba použít ověření DNS záznamem. Aby bylo vystavování možné zautomatizovat, budete potřebovat doménu hostovat u poskytovatele, který má podporované API pro úpravu DNS záznamů např. CloudFlare (viz dokumentace k nástroji CertBot)

Certifikáty dle certifikační autority

Vybírat můžeme z několika známých certifikačních autorit (CA). Jednu z nejširších nabídek certifikátů má Comodo (nově pod jménem Sectigo). Ze základních řad vás mohou zajímat především certifikáty PositiveSSL a EssentialSSL. První zmiňovaný patří k úplně nejlevnějším SSL certifikátům, druhý je jen o několik korun dražší. Technicky se jedná o identické certifikáty, jen k druhému se vztahuje vyšší podpora – například bezpečnostní scany vašeho webu, či možnost jednoduchého upgrade na EV certifikát.

Mezi další oblíbené certifikační autority patří RapidSSL, GeoTrust nebo Thawte (za všemi těmito certifikáty stála certifikační autorita Symantec, která však ztratila důvěru, protože neoprávněně vydala přes 30 000 certifikátů včetně testovacího certifikátu google.com, nové certifikáty podepisuje DigiCert a již s nimi není problém). Autorit je mnohem více, setkat se můžeme s certifikáty přímo od DigiCert, dále s GlobalSign, AlphaSSL, Certum, Symantec, Entrust nebo certifikáty velkých společností z oboru jako je třeba GoDaddy. Jednotlivé komerční certifikáty se liší také zárukou. Záruka se vztahuje na chybu certifikační autority, že by například certifikát vydala někomu jinému. Maximální kompenzace se pohybuje od 10 000$ u levných certifikátů po jednotky milionů $ u těch enterprise. Záruka se však vztahuje pouze na problémy autority, ne na bezpečnostní problémy na vaší straně.

Důvěryhodná CA je taková, která má svůj certifikát již předinstalovaný ve vašem operačním systému, prohlížeči (viz např. seznam CA v produktech Mozilla), nebo takovou, kterou jste si tam sami přidali (při přidávání je potřeba obezřetnost – nedůvěryhodná autorita může vystavit libovolné certifikáty). Pro použití na webu jsou vhodné ty, které jsou členy CAB.

Mnoho certifikačních autorit nabízí také různé „pečetě“ na web, aby návštěvník získal pocit bezpečí. Ty však slouží spíše k propagaci samotné CA a o jejich smyslu je nejlepší se přesvědčit A/B testem přímo na vašem webu.

Certifikáty je možné zakoupit na 1 rok (maximálně 398 dní). Platnost se historicky několikrát zkrátila, a ta aktuální vychází z rozhodnutí firmy Apple z března 2020 nepodporovat certifikáty vystavené na delší dobu. Prodejci certifikátu však často umožňují si certifikát předplatit na více let a budou jej každý rok obnovovat.

Mimo klasických komerčních certifikátů je možné pořídit si certifikát autority Let’s Encrypt, který je zcela zdarma. Na první pohled se může zdát nevýhoda, že je jeho platnost pouze 90 dní. V praxi to však vůbec nevadí, protože se počítá s jeho automatickým obnovováním pomocí protoklu ACME (Automatic Certificate Management Environment), takže skutečná administrativa je kolem něj menší než u komerčních certifikátů. Váš server však musí tento typ certifikátu podporovat a musí na něm běžet skripty k automatické obnově. O to by se měl typicky postarat váš webhoster. Technicky nemá certifikát Let’s Encrypt proti běžným komerčním certifikátům žádné nevýhody.

Pro vystavování certifikátů pomocí ACME protokolu na serveru můžete použít například nástroje CertBot, nebo ACME.sh. Pro vystavení certifikátu je potřeba prokázat vlastnictví domény. To lze dvěma hlavními způsoby – buď vystavením speciálního souboru na adresu http://<domena>/.well-known/acme-challenge/, nebo pomocí vytvoření speciálního DNS TXT záznamu (pro automatizaci je nutné programově ovládat DNS server, proto někteří poskytovatelé hostingu vyžadují, aby byla doména vedena u nich).

Kdy použít Let’s Encrypt a kdy komerční certifikát?

Jak již bylo zmíněno, samotný certifikát od autority neslouží k zabezpečení, ale k prokázání totožnosti – zabezpečení určuje použitá šifra, která je na certifikátu nezávislá. Z tohoto úhlu pohledu je tak jedno, jestli využijete komerční DV certifikát, nebo Let’s Encrypt – oba ověřují pouze to, zda máte k dané doméně přístup. Pokud usilujete o vyšší důvěryhodnost vašeho webu a chcete mít v certifikátu i jméno své společnosti, tak budete spíše chtít EV certifikát, který poskytují pouze komerční autority. Pro Let’s Encrypt je dále zásadní podpora tohoto certifikátu na serveru a zdaleka ne všichni webhosteři ji mají – v těchto případech je nutné opět použít běžný komerční certifikát. SSL certifikáty se nemusí používat pouze pro webové služby, ale i pro zabezpečení dalších komunikačních kanálů (VPN, RDP,…) a podepisování kódu či e-mailů – pro tyto účely budete většinou potřebovat komerční certifikát. Některá starší zařízení certifikátu Let’s Encrypt nedůvěřují, ale většinou jde jeho podpora doinstalovat, což vzhledem k jeho rozšíření mnoho uživatelů již dávno udělalo.

Další cestou, jak získat SSL certifikát zdarma, je použití CDN/Proxy typu CloudFlare. V tomto případě použijete DNS servery CloudFlare a veškerý provoz bude směrován do této služby, která v proxy módu do HTTPS provoz „zabalí“. Základní (a pro většinu použití dostatečná) varianta služby je zdarma. CloudFlare spolupracuje s Comodo a jsou použity DV certifikáty této certifikační autority (jsou použity multidoménové wildcard certifikáty a v jejich detailech tak můžete vidět další weby, které tuto službu využívají).

K Let’s Encrypt již existuje i alternativa – finská certifikační autorita Buypass nabízí službu Buypass Go SSL, která stejně jako Let’s Encrypt využívá protokol ACME a vystavuje zdarma důvěryhodné DV certifikáty s platností 180 dní.

V druhé polovině roku 2020 se do skupiny společností vystavující SSL certifikáty zdarma se přidala i společnost ZeroSSL. Ta nabízí i placené plány, které umožňují vystavit certifikáty s delší platností, nebo využívat REST API.

Pokud vám stačí ověření certifikátu jen podle domény (většinou ano) a nepočítáte s používáním velmi starých prohlížečů, je pro použití na webu certifikát Let’s Encrypt (nebo jeho důvěryhodná alternativa) naprosto dostatečný – ať už provozujete blog, firemní web, nebo e-shop.

Komerční certifikáty typicky nabízejí možnost si na web vložit logo autority/pečeť (trust logo/trust seal). Technicky nemá žádnou funkci, je to typicky kousek javascriptu nebo jen obrázek zobrazující logo certifikační autority. Může v očích některých návštěvníků zvyšovat důvěryhodnost webu (různé certifikace a odznaky mají rádi například v Německu), jde na něj však pohlížet i jako na marketingový kanál certifikačních autorit.

Jak získat SSL certifikát?

Certifikační řetězec se prakticky skládá ze 4 částí:

• Privátní klíč, který si vygenerujete a má k němu přístup pouze váš webový server a vy. Nikdy ho veřejně nesdílíme, neposíláme atd. Privátní klíč se typicky nemění ani když žádáme o nový certifikát, důvod pro jeho změnu je především, když dojde k jeho úniku.
• CSR (certificate signing request) – žádost o certifikát, jedná se o speciální soubor, který obsahuje veřejný klíč vygenerovaný z privátního a informace, které chcete podepsat (doména, společnost,…) – tento soubor se posílá certifikační autoritě k podepsání. Je dobré ho uschovat, protože díky němu můžeme jednoduše požádat o obnovení certifikátu. Z privátního klíče však lze kdykoliv vygenerovat nový.
• Certifikát podepsaný certifikační autoritou (leaf certificate) na základě CSR (většinou s koncovkou .pem nebo .crt)
• Mezilehlé certifikáty certifikační autority (intermediate certificates) – autorita nepodepisuje certifikát přímo, ale pomocí dalších (mezilehlých) certifikátů, které sama podepsala, a jsou tak také důvěryhodné. Je to proto, že pokud by při podepisování koncového certifikátu došlo k úniku dat, nebo je potřeba provést technologické změny, stačí vyměnit mezilehlý certifikát a není potřeba rušit celou autoritu ani řešit její opětovné dostání do seznamu důvěryhodných autorit operačních systémů.

Pro získání certifikátu potřebujete nejprve vygenerovat privátní klíč a následně z něj připravit CSR. Podíváme se jak na to.

Jak vygenerovat podklady pro SSL certifikát?

Nejpoužívanějším nástrojem pro generování certifikátů je knihovna OpenSSL, ta je běžně k dispozici v OS Linux, pro Windows je ji třeba doinstalovat například z https://slproweb.com/products/Win32OpenSSL.html.

Získání certifikátu tedy začíná vygenerováním privátního klíče. Někteří prodejci certifikátů mají k tomuto účelu nástroje, které vše vygenerují online, je však potřeba prodejci plně důvěřovat – nikdy nemůžete vědět, zda si náhodou váš klíč někde neuložil. Celý systém je navržen tak, že nikdo kromě vás k privátnímu klíči nemá a nepotřebuje mít přístup. Je proto vždy lepší si klíč vygenerovat samostatně. Pro každou doménu byste měli generovat unikátní privátní klíč

openssl genrsa -out domena.key 2048

Pokud klíč negenerujeme přímo na cílovém stroji, může být vhodné klíč opatřit heslem:

openssl genrsa -des3 -out domena.key 2048

Příkazy vygenerují privátní klíč ve formátu RSA o délce 2048 bitů. Délka klíče přímo ovlivňuje jeho sílu, některé staré aplikace si neporadí s delším klíčem než 1024 bitů, 2048 je aktuálně považováno za bezpečné, je však možné použít i klíč délky 4096 bitů – delší klíče však přinášejí i nutnost stáhnout více dat při jejich přenosu. To řeší výměna algoritmu RSA za kryptografii elastických křivek (ECC, klíč se pak označuje jako ECDSA), kdy je možné použít mnohem kratší klíč při zachování bezpečnosti. Starší aplikace však tuto metodu nepodporují, není podpora ani u všech certifikačních autorit a je potřeba často upravit konfiguraci serveru. Křivek je mnoho různých typů, nejrozšířenější však jsou „prime256v1“ a „secp384r1“. Vygenerovat klíč s elastickými křivkami je možné následujícím příkazem:

openssl ecparam -out domena.key -name prime256v1 -genkey

Dále je potřeba vygenerovat žádost o certifikát – soubor CSR, který následně autoritě předáme k podpisu. To uděláme následujícím příkazem a vyplníme parametry, na které se nás bude ptát:

openssl req -new -sha256 -key domena.key -out domena.csr

Bude se jednat především o následující údaje:

• Doména (CN – Common Name, Obecné jméno) – doména, pro kterou bude certifikát vystaven – pro wilcard certifikát to bude např. *.naswp.cz. U S/MIME certifikátů to je vaše jméno, u Code Signing jméno organizace.
• Společnost (O – Organization, Organizace) – jméno firmy
• Oddělení (OU – Organizational Unit, Jednotka organizace) – oddělení firmy, většinou můžete vyplnit IT, Marketing, Web,…
• Město (L – Locatily/City)
• Kraj (ST – State/Country/Region) – především pro státy USA, v našich podmínkách můžeme vyplnit kraj (např., Plzensky kraj), nebo jednoduše Czechia/Czech Republic
• Stát/Země (C)- dvou-písmenný ISO kód země – CZ, DE, PL,…
• E-mail – kontaktní e-mail správce, CA ho může použít pro řešení problémů.

Přestože všechny tyto údaje nejsou potřebné (pro vystavení DV certifikátu je potřeba prakticky jen CN), různé certifikační autority mohou některé z nich vyžadovat. Proto doporučuji při generování CSR vyplnit vše – to samé CSR následně můžete bez starostí využít i u jiných CA nebo pro jiné typy certifikátu.

Příkazy pro vytvoření klíče a CSR pro OpenSSL můžeme jednoduše vygenerovat v nástroji od DigiCert. Parametr -sha256 říká, že se k žádosti (veřejnému klíči s údaji k podepsání) vygeneruje podpis/hash typu SHA 2 – 256 bitů dlouhý, ten slouží autoritě k tomu, aby ověřila, že jste vlastník daného privátního klíče a data nebyla modifikována. Dříve se používal hash SHA 1 i MD5, ale se vzrůstajícím výkonem počítačů se zvyšuje i pravděpodobnost, že by se někomu mohlo podařit žádost zfalšovat.

Obsah CSR si můžete jednoduše zkontrolovat například v online nástrojích certifikačních agentur.

Soubor CSR s žádostí o vystavení certifikátu vypadá takto:

-----BEGIN CERTIFICATE REQUEST-----
MIIC...........
-----END CERTIFICATE REQUEST-----

Nástroje

Další možností, jak rychle jednoduše vygenerovat pár privátního klíče s veřejným klíčem v CSR, je nástroj autora článku SSLminiTool, který generuje 2048 bitový klíč a CSR se zadanými údaji.

Pro základní správu certifikátů lze použít i aplikaci certifikační autority DigiCert, která umožňuje i práci s Code Signing certifikáty.

Komplexnějším nástrojem pro dlouhodobou práci s SSL certifikáty je aplikace XCA, kterou lze použít i pro vytvoření vlastní interní certifikační autority.

Kde koupit komerční SSL certifikát?

Když máte vygenerovaný privátní klíč a žádost o certifikát, je potřeba certifikát objednat u nějakého z jejich prodejců, kteří mají typicky mnohem lepší ceny a podporu než samotná certifikační autorita.

Pro nákup mohu doporučit stránky SSL Mentor, které nabízí široký výběr certifikátů za dobrou cenu. Zmíním, že SSL certifikáty prodává i autor článku na poptávku.

Podle typu certifikátu dojde k ověření údajů a získáme soubor obsahující náš nový certifikát a většinou i mezilehlé certifikáty, které jsou důležité ke správné konfiguraci serveru.

Se samotným nasazením certifikátu by vám již měl pomoci váš webhoster. Některé hostingy za vás vyřeší i celou agendu s pořízením certifikátu – většinou za poplatek obsahující částku za certifikát a drobnou částku za vyřízení. V administracích některých hostingů jsou připravena pole pro vložení privátního klíče a certifikátu, který obdržíte od CA.

-----BEGIN PRIVATE KEY-----
MIIE...........
-----END PRIVATE KEY-----

Pokud do administrace musíte vkládat certifikát, je nutné ho doplnit i o certifikáty autority, výsledný soubor tak bude vypadat následovně:

-----BEGIN CERTIFICATE-----
MIIG…váš.certifikát……..
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIG…certifikáty.autority..
-----END CERTIFICATE-----

Pokud máte k dispozici pouze koncový certifikát pro doménu bez mezilehlých, je možné je jednoduše stáhnout pomocí nástroje Cert chain resolver. Celý řetězec certifikátů si můžete také stáhnout po testu v online nástroji SSL Server Test (ve výpisu je zde jako poslední uveden přímo certifikát autority, který ke konfiguraci nepotřebujete – je již obsažen v operačním systému/prohlížeči).

U webhostingů s podporou Let’s Encrypt většinou stačí HTTPS jen zapnout.

Pokud používáte vlastní server/VPS, můžete si proces získávání Let’s Encrypt zautomatizovat pomocí nástroje CertBot. Pro servery s MS Windows lze využít ZeroSSL.

HTTPS ve WordPressu

V předchozím textu jsme prošli obecné informace o SSL certifikátech a jak je získat. Pokud již máme certifikát nasazen, můžeme se vrhnout na praktickou konfiguraci, jak WordPress pro použití HTTPS nastavit.

Pokud se teprve chystáme WordPress nainstalovat, je vhodné to rovnou udělat přes HTTPS – vyhneme se tím mnoha problémům. Stačí pouze spustit instalátor na variantě URL adresy s HTTPS. Po instalaci pak bude zbývat vyřešit pouze přesměrování z nezabezpečené HTTP varianty.

Pokud se chystáme na HTTPS migrovat již běžící WordPress, bude postup trochu složitější – velmi podobný tomu, když migrujeme web na novou doménu. Prakticky se skládá ze 3 kroků:

1. Nastavení – změna adresy webu na variantu s HTTPS
2. Náhrada starých HTTP adres za nové na HTTPS
3. Nastavení přesměrování z HTTP na HTTPS

Nastavení WP

Tento krok je velmi jednoduchý – stačí přejít do Nastavení – Obecné a zde v obou adresách změnit http na https. Pokud máte pole ke změně adres zašedlé, budete mít tyto hodnoty pravděpodobně definované v souboru wp-config.php a je třeba je změnit tam.

Ukázka nastavení ve wp-config.php:

define('WP_SITEURL', 'https://naswp.cz');
define('WP_HOME', 'https://naswp.cz');

Po tomto nastavení půjde web stále otevřít na HTTP, ale veškeré generované odkazy (např. v menu) již povedou na variantu s HTTPS, přičemž tento protokol bude využívat i nově vkládaný obsah. Po tomto nastavení a před dalšími kroky je ideální otestovat, zda se web přes HTTPS opravdu načte (i když nebude vše zatím správně fungovat).

Pro kompletnost: ve WordPressu naleznete také konstantu FORCE_SSL_ADMIN, která vynutí používání HTTPS v administraci – frontend by tak mohl používat HTTP. Když už máte HTTPS zprovozněné, je vhodné ho použít všude dle výše uvedeného nastavení a tuto konstantu není potřeba nijak nastavovat.

Náhrada starých URL za nová

Tento krok je nejkomplikovanější. Problém je v tom, že WordPress na vše vytváří absolutní adresy, a tak například každý vložený obrázek obsahuje adresu s původní doménou na HTTP. Je tedy třeba projít celou databázi, najít staré adresy a změnit je na nové, jinak si prohlížeče budou stěžovat na smíšený obsah (mixed content).

Jednoduchou náhradu lze provést přímo v databázi SQL příkazem typu: UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://naswp.cz', 'https://naswp.cz'); – to však v naprosté většině případů nestačí…

Problém je s hodnotami s nastavením a widgety. Hodnoty jsou v databázi v tabulce wp_options uloženy serializovaně a každý řetězec má definovanou délku. Pokud se změní délka (přidá se „s“), tak se hodnota stane neplatná. Pro představu, hodnota „http://naswp.cz“ je uložena jako:

s:15:"http://naswp.cz"

15 je počet znaků, pokud tuto hodnotu změníme na https://naswp.cz, která má 16 znaků, nebudou nám čísla souhlasit a je potřeba tato serializovaná pole opravit.

Proto je potřeba náhradu provést nástrojem, který si s těmito problémy umí poradit.

Plugin: Better Search Repalce

Jedním z nástrojů, které si se serializovanými poli poradí je například plugin Better Search Replace.

Nastavení je velmi jednoduché. Stačí nastavit co čím chceme nahradit (http://naswp.cz => https://naswp.cz) a vybrat tabulky (pokud pluginy nepoužívají nějaké extra tabulky, bude se jednat o wp_posts a wp_options). Můžeme nejprve spustit náhradu nanečisto (dry run), kdy se můžeme podívat, co se nám nahradí.

V nastavení máme i volbu nahrazovat ve sloupci GUID (Replace GUIDs). Tuto volbu je potřeba používat s rozmyslem. Každý kousek obsahu má ve WP svůj jedinečný identifikátor, který je založený na url adrese. Ten využívají RSS čtečky (např. Feedly) a další konzumenti feedů, pokud by se změnil, budou si myslet, že je veškerý obsah nový a zobrazí ho znovu případnému uživateli. Pokud máte jistotu, že vaše feedy nikdo nevyužívá, můžete GUID změnit. To samé platí i v případě, že migrujete nový web z vývojového prostředí na produkci ke spuštění – žádné odběratele nemáte, můžete GUID bez problému změnit, což bych i doporučoval, protože z nich lze vyčíst adresa vývojového prostředí.

Podobnou funkcionalitu nabízí i plugin Search & Replace, který umí databázi před náhradou i zazálohovat.

Po úspěšném nahrazení adres je možné tyto pluginy odinstalovat.

Skript: Search & Replace for WP

Better Search Replace je založen na skriptu Search & Replace for WP.

Tento externí skript ke svému běhu nevyžaduje WordPress. Pokud jej chceme použít, tak je potřeba si především uvědomit, že tento a jemu podobné skripty, by neměly být v žádném případě ponechány volně na serveru, protože by je mohl zneužít útočník. K podobným nástrojům je vhodné omezit přístup pomocí .htaccess nebo pomocí služby Blocking.top, která do PHP souborů přidá různé možnosti omezení přístupu. O existenci tohoto skriptu se hodí vědět například pro případy, kdy se náhrada nezdaří, přestane fungovat WordPress a potřebujete nahrazení vrátit zpět.

WP-CLI

Pokud máte vlastní server a používáte WP-CLI, je náhrada adresy (včetně oprav serializovaných polí) velmi jednoduchá pomocí příkazu:

wp search-replace 'http://naswp.cz' 'https://naswp.cz' --skip-columns=guid --all-tables-with-prefix

Náhrada v JSON

Při náhradách můžete narazit na pluginy, které neuchovávají data jako serializovaná pole, ale jsou ve formátu JSON (například TablePress nebo GravityForms), kde jsou lomítka (/) escapovány zpětným lomítkem (\/). V tom případě je nutné provést ještě jednu náhradu http:\/\/naswp.cz za https:\/\/naswp.cz.

Přesměrování na HTTPS

Když nám varianta s https:// funguje, je vhodné přesměrovat všechny požadavky z HTTP na HTTPS. To lze udělat například pravidlem v .htaccess. Přesměrování na https může provést i samotný redakční systém (nebo plugin), ale to nedoporučuji, protože se tak musí zbytečně načíst celé jádro systému a přesměrování bude pomalé.

#http to https
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !on
  RewriteCond %{HTTP:X-Forwarded-Proto} !=https
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,QSA,NE,R=301]
</IfModule>

Pro připomenutí: samotné přesměrování v našem kódu má několik extra parametrů, některé z nich nejsou vždy nutné.

• L – Last – když jsou podmínky splněny, ukončí se zde vyhodnocování
• QSA – Query String Append – pokud jsou v původní URL nějaké parametry za ?, budou automaticky zachovány
• NE – No Escape – nebude se snažit přepsat případné speciální znaky – ty se používají například při autentifikaci s externími službami
• R=301 – Redirect 301 – samotné trvalé přesměrování kódem 301 Moved Permanently

Před úpravou souboru .htaccess si jej vždy raději předem zazálohujte. I drobný překlep zde může způsobit chybu 500.

Příklady pro webový server Nginx naleznete v příkladech konfigurace: https://github.com/lynt-smitka/WP-nginx-config.

Když jste si jistí, že vše funguje, je vhodné zlepšit bezpečnost využitím HTTP hlavičky HSTS (Strict Transport Security).

#HSTS
<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=15768000;" env=HTTPS
</IfModule>

Ta se snaží řešit problém útoku SSL Strip – ten využívá toho, že úvodní komunikace se serverem před přesměrováním může být po HTTP, a provoz tak lze modifikovat a přesměrování změnit na úplně jinou cílovou adresu. Díky HSTS si prohlížeč po první návštěvě pamatuje, že tento web nikdy nebude po HTTP dostupný a bude rovnou otevírat zabezpečenou variantu (což vám i zrychlí celý proces přesměrování). Pamatuje si to dobu uvedenou v parametru max-age v sekundách. I tak stále existuje malé riziko, že by útočník odchytl úplně první požadavek na daný server, to lze řešit zařazením vaší domény na takzvaný preload list, který interně prohlížeče používají. K tomu je potřeba, aby všechny vaše subdomény měly správně nastavené HTTPS a následně doplnit hlavičku o další 2 parametry: includeSubDomains; preload

Když toto budete mít splněno, můžete si na https://hstspreload.org/ požádat o zařazení na seznam. Mějte však na paměti, že je mnohem snadnější se na tento seznam dostat, než se z něj nechat odstranit.

Pro správné nastavení HSTS je při přesměrovávání lepší nejprve provést přesměrování na HTTPS a až následně řešit variantu s/bez www. Proběhnou tedy 2 přesměrování, ale díky tomu se hlavička nastaví na obě varianty, pokud je to třeba. Pokud chcete provést přesměrování na HTTPS a zároveň na správnou variantu s/bez www, podívejte se na následující příklady.

Práci s SSL certifikátem můžete dále ovlivnit nastavením DNS záznamu CAA, který říká, jaká autorita pro vaši doménu smí vystavovat certifikáty. Brání se tak vystavení certifikátu omylem. Zde je vhodné říci, že certifikační autority mají povinnost informace o všech vystavených certifikátech zveřejňovat v Certificate Transparency, a díky CAA tak lze odhalit nesprávně vystavené certifikáty. Tyto informace lze dohledat například na stránce https://crt.sh.

Existují i další standardy pro ověřování chybně vystavených certifikátů – například HTTP hlavička HPKP Aktuálně podporu HPKP ukončily Firefox i Chrome ve svých verzích 72, Opera ve verzi 66 (ostatní běžné prohlížeče podporu nikdy neměly). Dalším standardem je DNS záznam TLSA (DANE), ale ani ten v prohlížečích není příliš podporovaný.

Pokud máte k hlavní doméně nějaké další doplňkové, budete pravděpodobně chtít provést přesměrování jejich HTTP i HTTPS varianty na hlavní doménu. Mnoho poskytovatelů umožňuje provést pomocí aliasů přesměrování pouze z HTTP varianty. V tom případě pro vás může být řešením poskytovatel DNS, který toto přesměrování u domény nabízí. Tím může být již několikrát zmíněná služba CloudFlare. Z českých poskytovatelů toto nabízí například TELE3, který v rámci redirect hostingu vystavuje k doménám automaticky certifikát Let’s Encrypt.

Nasazení HTTPS pomocí pluginu

Stejně jako na mnoho jiných věcí ve WP existují pluginy pro nasazení HTTPS. Mezi oblíbené patří například Really Simple SSL nebo SSL Insecure Content Fixer.

Doporučuji je však používat maximálně jako dočasné řešení. Pluginy totiž ve většině případů fungují tak, že pouze změní nastavení WP (což je velmi jednoduchý krok) a následně provádějí přepisování odkazů z http na https za chodu a neupravují samotné zdroje v databázi. S tím se pojí několik problémů:

• Je vykonávána zbytečná činnost
• Klíčová funkcionalita webu se stává závislou na pluginu – pokud se plugin v budoucnu vypne, ohrozí se tím fungování celého webu

Fungování HTTPS byste proto neměli svěřovat pluginu, ale provést přechod na HTTPS tak, aby fungoval úplně od základu i s vypnutými veškerými pluginy.

Přechod na HTTPS ve WordPress 5.7

WordPress 5.7 s sebou přináší novou funkci na převod webu na HTTPS. Pokud web na HTTPS ještě neběží, najdete tuto funkci v Nástroje – Stav webu, kde se po doběhnutí testu objeví zpráva, že „Web nepoužívá protokol HTTPS„. Nyní stačí kliknout na tlačítko „Aktualizujte svůj web tak, aby používal HTTPS“.

Tato funkce na pozadí provede několik činností:

• Nastaví adresy webu na variantu s HTTPS – stejně jako byste to udělali ručně v Nastavení – Obecné.
• Na veškerý obsah aplikuje filtr, který za chodu provádí nahrazení http::// odkazů za https://.
• Nastaví hodnotu https_migration_required v databázové tabulce wp_options, která říká, že je filtr aktivní.

Je vidět, že tento princip migrace nemění adresy odkazů přímo v databázi (stejně jako jednoduché pluginy převod na HTTPS) a proto doporučujeme raději provést kompletní ruční proces náhrady.

Content-Security-Policy

Podobnou funkcionalitu, jako je nahrazování požadavků za chodu, zvládne v moderních prohlížečích i HTTP hlavička CSP: Content-Security-Policy: upgrade-insecure-requests. Tu je možné umístit do .htaccess případně do meta tagu.

<IfModule mod_headers.c>
  Header set Content-Security-Policy "upgrade-insecure-requests;"
</IfModule>

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

Díky ní, budou požadavky na HTTP automaticky měněny na HTTPS na straně prohlížeče.

Běžné problémy přechodu na HTTPS

Smíšený obsah

Již jsme zmiňovali problém smíšeného obsahu. I pokud provedete krok s náhradou http na https v databázi, může vám stále zbýt několik http odkazů. Ty se mohou nacházet napevno v šabloně nebo třeba v některém ze starých pluginů. Různé pagebuildery (např. Elementor) mohou generovat pro jednotlivé stránky vlastní CSS soubory, odkaz na http variantu tak může být i v nich. S identifikací vám může pomoci stránka Why not Padlock nebo developerská konzole prohlížeče (F12). Po nalezení problematických zdrojů je třeba provést úpravy, které mohou znamenat drobnou změnu v šabloně, ale mohou být i mnohem komplikovanější – http požadavek může například dynamicky vytvořit nějaký javascript. To již může být dostatečný důvod, proč použít plugin typu SSL Insecure Content Fixer nebo hlavičky CSP upgrade-insecure-requests – problém bude vyřešen poměrně rychle, a získáme tím čas na vyřešení podstaty. Rozhodně bychom se ale s takovým řešením problému neměli spokojit.

Smyčka přesměrování

Další problém, který nás může potkat, je smyčka přesměrování (redirection loop). Projevuje se tak, že po aktivaci HTTPS bude stránka donekonečna přesměrovávat sama na sebe, až skončí chybou prohlížeče („tato stránka obsahuje smyčku přesměrování“, „web vás přesměroval příliš mnohokrát a podobně“) a na web se vůbec nedostaneme.

To se stává v případě, že váš web je umístěn za speciálním proxy serverem, který dělá tzv. SSL offloading – dochází na něm k odšifrování a komunikace dále pokračuje přes HTTP. U některých webhostingů se tak může dít na vstupu do sítě, kde je umístěn silnější server, který řeší šifrování. Často se s tím můžeme setkat také u loadbalancerů – strojů, které rozdělují zátěž na více webových serverů. V neposlední řadě to dělá také služba CloudFlare v konfiguraci Flexible SSL – je lepší využívat nastavení Full, které vyžaduje celou komunikaci na HTTPS (varianta Full strict, navíc vyžaduje validní certifikát na serveru – bez strict varianty tak můžete například používat interní certifikát hostingu Wedos, který by s přísnější variantou nefungoval).

To, že je to právě váš případ, poznáte podle toho, že při komunikaci přes port 443 přichází požadavky na webový server přes port 80 – ukáže vám to například skript proxytest.php.

Pokud k tomu dojde, je třeba instruovat WordPress, že už na HTTPS běží. K tomu je potřeba doplnit do wp-config.php blok, který bude kontrolovat hlavičku X_FORWARDED_PROTO, do které proxy servery standardně vkládají informaci o původním protokolu.

if (
   isset(      $_SERVER['HTTP_X_FORWARDED_PROTO']) &&
   'https'== $_SERVER['HTTP_X_FORWARDED_PROTO']) { 
   $_SERVER['HTTPS']='on';
}

Tento kód musí přijít kamkoliv před poslední řádek require_once(ABSPATH . 'wp-settings.php'); – je vhodné ho dát například hned za otevírací značku <?php – díky tomu bude úprava na první pohled hned vidět. Při špatném umístění můžete dostat při přístupu do administrace chybu Nemáte dostatečné oprávnění pro přístup na tuto stránku.

Kód funguje pouze v případě, že je proxy server správně nastaven a vrací hlavičku HTTP_X_FORWARDED_PROTO. Pokud jste pomocí proxytest.php zjistili, že jste za proxy, ale hlavička není vrácena, kontaktujte poskytovatele hostingu, ať chybu napraví. Provizorně se můžete pokusit problém vyřešit tím, že odstraníte z kódu test hlavičky a ponecháte pouze řádek $_SERVER['HTTPS']='on'; – může to však způsobit problémy s HTTP variantou.

Extrémním případem může být kombinace CloudFlare Flexible SSL a proxy serveru na straně webhostingu, která vám přepíše původní hlavičku X_FORWARDED_PROTO (s Flexible SSL uvidíte v testovacím skriptu vždy http). V těchto případech je lepší zamyslet se nad změnou komunikačního řetězce (nepoužívat Flexible SSL, nasadit HTTPS certifikát na hostingu, změnit hosting). Pokud opravdu potřebujete tuto kombinaci používat, je možné pravidla upravit pro hlavičku CF_VISITOR.

V případě, že se vám problém nedaří vyřešit, zkuste ještě stránky načíst v anonymním okně nebo jiném prohlížeči – může se stát, že si váš aktuální prohlížeč pamatuje starší nevhodnou konfiguraci.

Pokud chcete vyzkoušet jak se projevují rozličné problémy s SSL certifikáty, navštivte stránky BadSSL, kde můžete chování vyzkoušet přímo ve svém prohlížeči.

Různé chybové stránky

Může se stát, že se po aktivaci HTTPS objeví chybová stránka. Je možné, že se zobrazí pouze bílá stránka, v tom případě můžete zjistit kód chyby v developerské konzoli prohlížeče (F12) – nejčastěji to bude chyba 500.

• Obecná chyba 500 (Internal Error) – mohla nastat chyba v nějaké komponentě WordPressu, v tom případě zkuste zapnout zobrazování chybových hlášek – vložte/upravte řádek define( ‚WP_DEBUG‘, true ); ve wp-config.php. (poznámka: zapnutí původního zobrazování chyb)
• Pokud se stále nezobrazila chybová hláška, pravděpodobně máte chybu v souboru .htaccess – zkuste si ho zazálohovat a dočasně ho z hostingu smazat – pokud WP najede (nebudou fungovat trvalé odkazy), tak víte, že máte chybu hledat v něm.
• Prohlížeč si také může stěžovat, že nesedí common name – chyba ERR_CERT_COMMON_NAME_INVALID. To znamená, že nemáte certifikát vystavený pro správnou doménu. Může vám například chybět nějaká z www/bez www variant, nebo jiná doména z řetězce přesměrování – tuto skutečnost je třeba ověřit v detailech certifikátu (je třeba prohlédnout alternativní jména v certifikátu). U některých hostingů je třeba po aktivaci certifikátu nějakou dobu počkat (např. Wedos), nebo přeuložit nastavení domény (např. Savana), než se změna certifikátu projeví – pokud problém přetrvává několik hodin, kontaktujte podporu.
• V případě, že jste měnili DNS servery (např. kvůli migraci na CloudFlare), nebo prováděli změny DNS záznamů, je vhodné zkontrolovat, zda je změna již viditelná v internetu. Pro kontrolu můžete využít třeba DNS Checker (kontrolujte především NS a A záznamy).
• U některých hostingů můžete po aktivaci certifikátu dostat chybu Not Found on Accelerator, to v případě, že hosting používá složitější infrastrukturu a SSL certifikáty obhospodařuje ještě další server umístěný před vaším webem a informace o novém certifikátu se k němu ještě nedostala. V tomto případě musíte nějakou dobu počkat. Pokud se problém sám nevyřeší do několika jednotek hodin, kontaktujte podporu hostingu. S tímto problémem se můžete setkat například u hostingu Wedos, který používá Apache Traffic Server (ATS).
• Tento web není dostupný – ERR_CONNECTION_TIMED_OUT nebo ERR_CONNECTION_REFUSED – tato chybová hláška znamená, že server vůbec na zabezpečeném portu nenaslouchá, nebo je port blokovaný firewallem. Ověřit tuto skutečnost můžete online skenem otevřených portů , do kterého zadáte vaši doménu (bez http(s)://). Pokud je port dostupný, uvidíte 443 https ve výsledku. Pokud se prokáže nedostupnost portu, je třeba tuto skutečnost řešit s vaším hostingem/správcem serveru.
• K chybám u nového certifikátu může dojít i v případě, že je na počítači posunutý čas – datum vystavení tak může být v budoucnosti. Abyste se podobným problémům vyhnuli, nechte si čas synchronizovat z internetu.
• SSL_ERROR_PROTOCOL_VERSION_ALERT, ERR_SSL_VERSION_OR_CIPHER_MISMATCH – váš prohlížeč pravděpodobně nepodporuje na serveru nastavené verze TLS a šifer (viz teorie), je vhodné používat novější prohlížeč, nebo dohodnout rozšíření pravidel na serveru. Jaké šifrovací technologie váš prohlížeč podporuje můžete otestovat online. Tyto chyby mohou způsobit i některé antivirové programy, když mají nastaveno skenování HTTPS provozu a mění tak jeho parametry za chodu.
• Pokud dojde ke změně certifikátu můžeme narazit na cache prohlížeče, který si pamatuje předchozí konfiguraci a hlásí tak neplatný certifikát. V tomto případě pomůže restart počítače, nebo vyčištění cache stavu certifikátů (inetcpl.cpl – Obsah – Vymazat stav protokolu SSL).
• Web nefunguje na Apple zařízeních (Safari, iOS), v některých prohlížečích vrací NSPOSIXErrorDomain:100 nebo jen ERR_FAILED. Problém je v nastavení serveru (je za sebou webový server Nginx a Apache) a je chybně posílána HTTP hlavička Upgrade. Problém musí vyřešit správce serveru opravou konfigurace (Nginx trouble ticket, vysvětlení problému).
• Speciálnějším typem problému je neaktualizované komponenty na straně hostingu, problém se projevuje tak, že se nedaří komunikovat s některými externímu službami, nemusí fungovat aktualizace a nástroj „Stav webu“ hlásí chyby typu http_request_failed (např. cURL error 28: Connection timed out nebo cURL failed with error #60: SSL certificate problem: unable to get local issuer certificate nebo certificate expired). Problém může mít několik příčin. Jedna z nich je, že server nezná novější certifikáty certifikačních autorit a proto se ze strany serveru nedaří navázat spojení. Problém musí vyřešit správce serveru aktualizací CA bundle (většinou aktualizací balíčku ca-certificates nebo stažením certifikátu ze stránek cURL). Problém také může být nesprávně nastavená proměnná curl.cainfo v konfiguraci PHP. Můžeme se setkat také v příliš starou knihovnou OpenSSL, který nepodporuje novější protokoly, jako je TLS1.2.
• Výše zmíněný problém, kdy cURL hlásí expirovaný certifikát (error #60) může být způsoben změnou v certifikační autoritě Let’s Encrypt od 30. září 2021 a hosting na to nestihl zareagovat. cURL je knihovna, která zajišťuje HTTP komunikaci s dalšími servery a pokud WordPress potřebuje komunikovat do světa – například ke kontrole aktualizací, instalaci šablon a pluginů, ale i sám se sebou například k využití API – používá právě funkce této systémové knihovny. Pokud tedy v chybové hlášce vidíte zmínku o cURL, jedná se o problém v komunikaci ze strany serveru a typicky nemá nic společného s vaším SSL certifikátem, který používáte na svém webu. V případě, že na serveru nejsou certifikáty aktualizované, nebo jsou použity staré verze OpenSSL 1.0.2 a nižší, jeví se certifikát Let’s Encrypt expirovaný a nedaří se tak navázat jakoukoliv komunikaci se službami, které certifikáty LE využívají. WordPress obsahuje vlastní balíček aktualizovaných certifikátů (/wp-includes/certificates/ca-bundle.crt), nemůže však vyřešit zastaralé komponenty na serveru. Problém by měl v první řadě vyřešit hosting a je třeba toto řešit s podporou, lze je odkázat na info z OpenSSL.org.
• V březnu 2020 skončila podpora protokolů TLS 1.0 a TLS 1.1 a tak lze počítat s tím, že prohlížeče začnou označovat weby, které tyto protokoly používají za nezabezpečené. Např. Apple oznámil, že ze svých produktů bude podporu těchto protokolů odstraňovat a je možné, že od iOS 16 bude před weby s těmito protokoly varovat.

Certifikáty pro jiné účely

Jak bylo v článku několikrát zmíněno, certifikáty lze využít mimo HTTPS na webu i k dalším účelům. Zde je několik tipů jaký certifikát kde zvolit:

• Podepisování a šifrování e-mailů – zde je potřeba osobní certifikát typu S/MIME, lze doporučit Comodo nebo Certum, obě autority nabízejí certifikáty lišící se rozsahem podepsaných údajů. Aby byl obecně platný, musí mu důvěřovat mailoví klienti. Seznam autorit pro: Gmail, Mozilla (Thunderbird), Microsoft Windows (Outlook), Apple.
• Podepisování PDF – je potřeba stejný typ certifikátu jako pro podepisování e-mailů, jen je potřeba pohlídat, aby daná autorita byla členem AATL – v tomto seznamu bohužel nenalezneme Comodo, polské Certum zde však je. Dokumenty MS Office lze podepisovat i certifikáty Comodo.
• Komunikace se státní správou – potřebujete tzv. kvalifikovaný certifikát, ty vydávají pouze 
  Česká pošta, První certifikační autorita a eIdentity – první 2 jsou i členy AATL a lze je tak použít pro podepisování PDF, a jejich kořenové autority jsou i v základu ve Windows, tak je lze použít jako elektronický podpis pro příjemce s Outlookem.
• Podepisování kódu – potřebujete tzv. Code Signing certifikát, který je nastaven pro jiné použití než běžný SSL certifikát. Místo domény se zde validuje jméno společnosti, jedná se tedy o OV certifikát. Pokud chcete, aby vaše aplikace spolehlivěji prošla MS SmartScreen filtrem, je třeba zakoupit EV certifikát.
• VPN (např. IKEv2), RDP – pro tyto speciální služby jsou většinou vhodné stejné certifikáty jako pro HTTPS mimo wildcard – domény zde musí být jasně vypsány.

Co otestovat po nasazení?

Po nasazení SSL certifikátu je vhodné otestovat několik věcí:

• Nastavení šifrování pomocí nástroje SSLtest. Není důvod mít nižší skóre než A+.
• Kontrola celého webu, zda nenačítá nezabezpečené zdroje – pomohou vám nástroje jako je Xenu nebo ScreamingFrog.
• Pokud na nějaké stránce prohlížeč hlásí, že web není zabezpečený, zkuste zjistit proč nástrojem Why not Padlock nebo z vývojářské konzole prohlížeče.
• Zkontrolujte si i robots.txt zda neobsahuje odkaz na sitemap s http a zda soubor sitemap má již nové odkazy. V Google Search Console přidejte web jako nový a vyměňte odkaz na sitemap.
• Je dobré změnit protokol i v Google Analytics a zkontrolovat, zda Seznam.cz web s https indexuje.
• Zkontrolujte si protokol v, pro vás důležitých, externích odkazech (firmy.cz,..)
• Pokud používáte další služby, které jsou vázané na přesnou URL adresu, zkontrolujte jejich nastavení (Disqus, různé CDN,…)

Krátké shrnutí

Jaký vybrat certifikát?

• Pokud váš webhoster nepodporuje HTTPS, je lepší se podívat po jiném, nebo využít službu CloudFlare.
• Pokud váš webhoster podporuje Let’s Encrypt, bude vám ve většině případů dostačovat.
• Pokud pro vás není důležitý „zelený řádek“ (který se dnes již stejně nezobrazuje) a chcete levný certifikát, může být vhodným Comodo Positive SSL.
• Pokud vaše firma provozuje několik webů na různých doménách a potřebujete garantovat, že to jsou opravdu vaše weby, sáhněte po EV certifikátu.

Jak získat certifikát?

• V případě Let’s Encrypt stačí většinou jen zapnout podporu v administraci hostingu.
• Pro komerční certifikát potřebujete vygenerovat privátní klíč a žádost o certifikát CSR – s tím vám pomůže například nástroj SSLminiTool.
• Komerční certifikát získáte například u prodejce SSL Mentor.
• Lze využít službu nabízející SSL Offloading/Proxy. Tou je například CloudFlare, nebo bezpečnostní služby typu Sucuri.

Jak nastavit webhosting pro podporu HTTPS?

Každý webhosting má svou vlastní administraci, různé nastavení a podmínky. U některých hostingů je HTTPS samozřejmostí a zdarma, jinde je třeba dokoupit extra službu. Rozcestník do dokumentací známých hostingů:

• Active 24 – automaticky LE zdarma, možnost vlastního certifikátu
• Český Hosting – možnost zapnout LE zdarma; vlastní certifikát za poplatek 242 Kč ročně
• Forpsi – LE certifikát, certifikát autority Actalis S.p.a. zdarma, vlastní certifikát; aktivace přes podporu, nutno dokoupit SSL službu za 726 Kč ročně
• One Bit – automaticky LE zdarma, za příplatek GlobalSign nebo vlastní
• Savana – LE/vlastní certifikát, nutno dokoupit balíček SSL Plus za 145 Kč ročně
• Svět Hostingu – možnost zapnout LE zdarma, možnost vlastního certifikátu
• Váš Hosting – možnost zapnout LE zdarma; možnost zakoupit/dodat vlastní certifikát
• WP Hosting – možnost zapnout LE certifikát zdarma
• Wedos – interní certifikát, LE nebo vlastní za poplatek 144 Kč ročně

Jak nastavit WordPress?

• V Nastavení – Obecné změnit adresu webu z http:// na https://.
• Je potřeba provést náhradu starých odkazů za nové – např. pomocí Better Search Replace.
• Provést přesměrování z HTTP na HTTPS a nastavit hlavičku HSTS.
• Pokud prohlížeč stále hlásí nezabezpečený web, zkuste zjistit důvod například nástrojem Why not Padlock.

V tomto článku jste se mohli dočíst základní informace o HTTPS , k získání SSL certifikátu, k jeho nastavení ve WordPressu a k řešení běžných problémů. Pokud vám v článku něco chybí, nebo není jasné, zeptejte se v komentářích.

Spousty dalších informací o provozování webových stránek na WordPressu se samozřejmě dozvíte na konferencích WordCamp, kde se s vámi rádi potkáme. Sledujte WordPress Česko na FB pro info o aktuálním dění. P.S. Víte, že jsme i na Slacku?