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:
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). 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).
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:
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.
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í.
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:
Pokud máte možnost použít HTTP/2, určitě ji využijte. Zda váš web podporuje HTTP/2 můžete otestovat online.
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:
Certifikáty pro webové stránky se liší v několika ohledech. První rozdělení je podle toho, jaké údaje jsou certifikovány.
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.
Dalším typem rozdělení je podle počtu domén, které podepisují.
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.
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.
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)
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).
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í).
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.
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.
Certifikační řetězec se prakticky skládá ze 4 částí:
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.
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:
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-----
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.
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.
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ů:
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.
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.
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.
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.
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
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.
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é.
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.
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ů:
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.
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í:
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.
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.
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.
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.
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.
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:
Po nasazení SSL certifikátu je vhodné otestovat několik věcí:
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ů:
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?
