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:

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 (postupně vzniká snaha verze 1.0 a 1.1 přestat podporovat). Aktuální verzí je 1.3 a přináší mnoho benefitů především v oblasti výkonu.

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) 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).

Odposlech HTTPS - SNI.
Ukázka ze zachycení síťové HTTPS komunikace – doména je čitelná ve SNI

Ukázkovou konfiguraci pro váš server si můžete nechat vygenerovat 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 klientem domluví na první, kterou mají společnou. Kombinace vypadá typicky vypadá 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é.

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.
  • Můžete použít moderní a rychlý protokol HTTP/2, který umí podstatně zrychlit načítání zdrojů. Navíc lze také použít TLS1.3, díky kterému se zrychlí i samotná inicializace spojení.
  • Z marketingového pohledu je HTTPS podmínka 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.

Rychlost načítání s HTTPS.
Zpoždění způsobené navazováním HTTPS spojení je často zanedbatelné.

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í rozšíření 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 „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 – například v bankovnictví. Pokud je však vaší hlavní motivací mít zelený řádek, uvědomte si, že na řadě mobilních prohlížečů není pro běžné uživatele rozpoznatelný od běžného DV certifikátu. Tento trend časem pravděpodobně pronikne 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ý.

EV certifikát v Chrome - zelený řádek.
EV certifikát – zelený adresní řádek v Chrome (verze 70)
Stránka s EV certifikátem v IOS (Safari)
Stránka s EV certifikátem v Chrome Canary (verze 73)

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řebujte 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 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 k 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é.

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 PositiveSSLEssentialSSL. 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.

CA Comodo se přejmenovala na Sectigo.

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, 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 do 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ě.

Další oblíbené certifikační autority - Thawte, GeoTrust,  RapidSSL.

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 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 nebo 2 roky.

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, 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.

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á 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í).

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 na základě CSR (většinou s koncovkou .pem nebo .crt)
  • Mezilehlé certifikáty certifikační autority – 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), 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. 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 – 256bitů 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 2048bitový klíč a CSR se zadanými údaji.

Nástroj pro generování CSR od Lynt.cz.

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-----

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 WordPress

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 a 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 zmigrovat 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.

Aktivace HTTPS ve WordPress
V nastavení stačí změnit URL z http na https

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.

Pro kompletnost: ve WordPress 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 dlě výše uvedeného nastavení a tuto konstantu není potřeba nijak natavovat.

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).

Chyba - 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í.

Plugin pro pomoc s převodem WordPress z HTTP na HTTPS - Better Search Replace.

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í.

Skript: Search & Replace for WP

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

Tento externí skript, který 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ává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.

WP-CLI

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

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

Náhrada v JSON

Při náhradách můžete narazit na pluginy, které neuchovávají data jako serializované pole, ale ve formátu JSON (například TablePress), 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.

#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
Ukázka celého standardního .htaccess s přesměrováním.

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).

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.

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 (její použití je však poměrně náročné a proto se postupně přestává používat) nebo DNS záznam TLSA, který provádí obdobnou věc pomocí DNS, není však příliš podporovaný.

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.

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ů. 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.

Úkázka problému se smíšeným obsahem.
Ukázka problému se smíšeným obsahem z
Why not Padlock

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 – na web se vůbec nedostaneme.

Chyba smyččky přesměrování - ERR_TOO_MANY_REDIRECTS
Chybová hláška při smyčce přesměrování v Chrome

To se stává v případě, že váš web 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).
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.

Test SSL Offloading proxy - např. CLoudFlare
Výstup ze skriptu proxytest.php pro detekci proxy serveru

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.

Smyčka přesměrování - řešení úpravou wp-config.php
Ukázka úpravy wp-config.php pro odstranění smyčky přesměrování

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ě můžete 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ůžete to však způsobit problémy s HTTP variantou.

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.

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ů.
  • 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.
  • 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 Padlocknebo 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.
  • Zkontrolujte si protokol v pro vás důležitých externích odkazech (firmy.cz,..)

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 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 opravu 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.

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?

Líbil se Vám příspěvek a rádi byste podpořili WordPress - hlavně lidi okolo něho?
Sdílejte ho s přáteli.
Případně nám napište komentář.

1 komentář u “HTTPS a WordPress – podrobný průvodce”

Napsat komentář

This site uses Akismet to reduce spam. Learn how your comment data is processed.