Přepnout na široké zobrazení

Jak na HTTPS na vlasním serveru



Úvod

Zabezpečení komunikace s webem pomocí šifrovaného protokolu HTTPS již dnes není nic, co by používaly pouze banky, webmaily nebo jiné služby, které pracují s citlivými údaji. Dnes by se HTTPS mělo používat na co nejvíce službách, protože s rozmachem smartphonů a cestování se připojujeme k hromadě sítí (kavárny, letiště, restaurace, knihovny, ...), přičemž některé jsou na tom s důvěryhodností ne úplně dobře.
Útok na takové veřejné Wi-Fi není nic drahého ani technicky náročného, přičemž následná manipulace s nezašifrovaným provozem není o nic těžší a může mít nepěkné následky, jak koneckonců dokazuje například tato přednáška od Tomáše Hály z webhostingové společnosti Active24. Pokud náhodou máte web u této společnosti, tak už HTTPS nasazené máte, a možná o tom ani nevíte. :-) HTTPS proti těmto útokům brání, přičemž pokud se kdokoliv pokusí do provozu zasáhnout, tak se zobrazí celoobrazovkové varování, že certifikát je neplatný. Toto jste jistě už někdy zažili. Pouhé čtení tohoto provozu už je zapovězeno principielně, a to právě již zmiňovaným šifrováním.
Nemusí však jít pouze o nedůvěryhodné veřejné Wi-Fi sítě. V některých zemích se to děje i na normálním placeném připojení, např. v Číně. Můžete sice namítat, že tady v Číně nejsme, nicméně co když se vám nebo vašemu ISP někdo nabourá do routeru či klidně přímo do počítače? Pouze jednoduchým změněním adres DNS serverů se dají dělat divy. Odkloní doménu na útočníkovu IP adresu a pár transparentních proxy serverů se už o "legrácky" postará. Tomuto se říká DNS hijacking.
Rozmach HTTPS navíc není nijak malý, jak ukazuje například tento graf od certifikační autority Let's Encrypt, o které dnes ještě uslyšíte. Pokud chcete i jinou motivaci, tak vězte, že již od roku 2014 dává Google malinko bodíků vaší stránce navíc, pokud běží přes HTTPS, takže se můžete ocitnout o malinko výše ve výsledcích (no dobře, nijak extrémní boost to nebude, ale vždyť pro bodík navíc v Googlu uděláte cokoliv, nu ne? :-)). Proč se tedy nepřipojit k 90% načteným stránkám a nezavést HTTPS taky?
V tomto článku vám ukážu, jak HTTPS nasadit na vlastním serveru, tzn. nějakém, na kterém máte roota (ať už je to server fyzický, nebo VPS). Pokud používáte sdílený webhosting (jako ostatně asi většina lidí), HTTPS si musíte nastavit u nich. V dnešní době již není výjimkou, že se tak dá učinit prakticky na jeden klik v administraci a vůbec se nemusíte pouštět do nějakých terminálových machinací, které budu popisovat níže. Jestliže takovou možnost nenajdete, kontaktujte customer support. Pokud je dotyčný hosting alespoň trošku slušný, to možnost by vám dát měl. Některé hostingy dnes už HTTPS s validním certifikátem zapínají automaticky a ani o tom třeba nevíte (stejně tak činí různé reverse proxy as-a-service typu Cloudflare).
Nutno podotknout, že ukázku budu provádět na operačním systému Debian 10 Buster s webserverem Apache 2.4. Pokud bude vaše prostředí jiné, nemusí vše fungovat správně, stejně jako když se mými pokyny budete řídit o nějaký ten měsíc/rok dále (dnes je 1. 1. 2020, abyste se orientovali) a může to nadělat neplechu. Jestliže se cokoliv pochroumá, nenesu za to zodpovědnost; vše děláte na vlastní nebezpečí. I zde platí pravidlo, že byste měli pravidelně zálohovat. Zároveň podotýkám, že mířím výhradně na malé, nekomerční a osobní prezentace, kde nebude vadit, když něco chvilku nepoběží. Pro nějaké větší nasazení je dobré se vzdělat jinak a jinde.
Informace se budu snažit podávat detailně a budu vysvětlovat na první pohled nejasné pojmy. Za cíl si dávám, aby to zvládl i naprostý laik a Linuxu neznalý uživatel. Teď už proto nikdo nebude moct říci, že je to moc složité. :-) Proto bude článek dost dlouhý a ukecaný. Pokud se vám tento styl nelíbí, tak na si můžete samozřejmě najít nějaký jiný; podobných (a stručnějších) je na webu mnoho; na spodku stránky jsem vám vypsal seznam. Pojďme tedy na to.


1. Získání certifikátu

Aby si klient mohl ověřit, že jsou naše stránky opravdu ty naše a nikdo mu je po cestě nepodvrhl ani nerozšifroval, musíme mít důvěryhodný certifikát. Nyní si ukážeme, jak ho získat. Nebojte se však, je to, narozdíl od dob minulých, dnes všechno zdarma a automaticky.
Důvěryhodné certifikáty vydává entita, které se říká certifikační autorita (dále CA). Jednou z nich je Let's Encrypt, která z této množiny vyniká tím, že jsou její certifikáty naprosto zdarma, a to jak pro komerční, tak nekomerční použití. Certifikáty od této CA mají platnost 90 dnů (cca 3 měsíce) a získávají se a obnovují se zcela automaticky (pokud si neřeknete, že to tak nechcete).
První krok, co musíme udělat, je stáhnout nějakého klienta, který umí komunikovat po protokolu ACME, který se domluví s CA. Jedním z nich je acme.sh. Klient se spojí s certifikační autoritou, ta si ověří, že komunikuje opravdu s námi (aby si nikdo jiný nemohl důvěryhodný certifikát udělat pro cizí doménu a poté se za ni vydávat) a pokud je ověření úspěšné, certifikát nám vydá. Tento klient je můj oblíbený a vyznačuje se tím, že je napsán přímo ve skriptovacím jazyce shellu bash. Žádné C++, žádný Python ani hromada dalších závislostí.
Nejprve nainstalujeme program curl následujícím příkazem:
sudo apt install curl
  user@DebianVM:~$ sudo apt install curl
  Načítají se seznamy balíků… Hotovo
  Vytváří se strom závislostí
  Načítají se stavové informace… Hotovo
  Následující dodatečné balíky budou instalovány:
    libcurl4
  Následující NOVÉ balíky budou nainstalovány:
    curl libcurl4
  0 aktualizováno, 2 nově instalováno, 0 k odstranění a 0 neaktualizováno.
  Nutno stáhnout 596 kB archivů.
  Po této operaci bude na disku použito dalších 1 123 kB.
  Chcete pokračovat? [Y/n] y
  Stahuje se:1 http://ftp.cz.debian.org/debian buster/main amd64 libcurl4 amd64 7.64.0-4 [332 kB]
  Stahuje se:2 http://ftp.cz.debian.org/debian buster/main amd64 curl amd64 7.64.0-4 [264 kB]
  Staženo 596 kB za 1s (673 kB/s)
  Vybírá se dosud nevybraný balík libcurl4:amd64.
  (Načítá se databáze … nyní je nainstalováno 178471 souborů a adresářů.)
  Připravuje se nahrazení …/libcurl4_7.64.0-4_amd64.deb …
  Rozbaluje se libcurl4:amd64 (7.64.0-4) …
  Vybírá se dosud nevybraný balík curl.
  Připravuje se nahrazení …/curl_7.64.0-4_amd64.deb …
  Rozbaluje se curl (7.64.0-4) …
  Nastavuje se balík libcurl4:amd64 (7.64.0-4) …
  Nastavuje se balík curl (7.64.0-4) …
  Zpracovávají se spouštěče pro balík man-db (2.8.5-2) …
  Zpracovávají se spouštěče pro balík libc-bin (2.28-10) …
  user@DebianVM:~$
        
Je ale docela možné, že ho již nainstalovaný máte, aniž byste o tom věděli; je poměrně populární a používaný. Ten bude použit pro samotné stažení skriptu a později pro komunikaci skriptu s CA.
Poté již můžeme stáhnout a naistalovat samotný acme.sh pomocí příkazu:
curl https://get.acme.sh | sh
  user@DebianVM:~$ curl https://get.acme.sh | sh
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
  100   705    0   705    0     0   2259      0 --:--:-- --:--:-- --:--:--  2259
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
  100  190k  100  190k    0     0   389k      0 --:--:-- --:--:-- --:--:--  388k
  [St led  1 21:11:02 CET 2020] Installing from online archive.
  [St led  1 21:11:02 CET 2020] Downloading https://github.com/Neilpang/acme.sh/archive/master.tar.gz
  [St led  1 21:11:04 CET 2020] Extracting master.tar.gz
  [St led  1 21:11:04 CET 2020] It is recommended to install socat first.
  [St led  1 21:11:04 CET 2020] We use socat for standalone server if you use standalone mode.
  [St led  1 21:11:04 CET 2020] If you don't use standalone mode, just ignore this warning.
  [St led  1 21:11:04 CET 2020] Installing to /home/user/.acme.sh
  [St led  1 21:11:04 CET 2020] Installed to /home/user/.acme.sh/acme.sh
  [St led  1 21:11:04 CET 2020] Installing alias to '/home/user/.bashrc'
  [St led  1 21:11:04 CET 2020] OK, Close and reopen your terminal to start using acme.sh
  [St led  1 21:11:04 CET 2020] Installing cron job
  no crontab for user
  no crontab for user
  [St led  1 21:11:04 CET 2020] Good, bash is found, so change the shebang to use bash as preferred.
  [St led  1 21:11:05 CET 2020] OK
  [St led  1 21:11:05 CET 2020] Install success!
  user@DebianVM:~$
        
Skript se sám nainstaluje do vašeho domovského adresáře a po dalším spuštění terminálu ho bude možné používat jednoduchým zadáním příkazu
acme.sh
. Jedna z pěkných vlastností tohoto skriptu je, že pro jeho instalaci není třeba být přihlášen jako root, címž se liší od klasických instalací balíčků pomocí
apt
apod. Bez těchto oprávnění ho lze i spouštět a používat mj. v tzv. webroot modu, který budeme používat.
Pro pokročilejší: pokud nechcete instalovat skript takto, můžete si ho naklonovat z GitHubu. Vše je open-source, takže žádný problém.
Nyní už jsme připraveni na získání samotného certifikátu. Mějme doménu www.priklad.cz, která má webroot (tzn. kořenová složka webu, odkud se servírují soubory) v /var/www/html (pozn. na konci cesty by nemělo být lomítko).
Důležité je říct, že do složky musíte mít právo zapisovat pod uživatelem, pod kterým skript spouštíte (pozn. pod rootem toto z principu řešit nemusíte; root může totiž vše)! Stejně tak pokud vám nějaký redakční systém odchytává všechny požadavky, tak mu musíte nařídit, aby to nedělal pro složku <webroot>/.well-known/acme-challenge/ a její podsoubory. Jestliže máte domén víc, stačí přidat víc argumentů -d <doména>. Skript se s tím umí poprat.
Pokud jste se ujistili, že vše je nastaveno jak má, stačí už spustit příkaz podobný tomuto, kde nahradíte doménu/y a webroot za ten váš:
acme.sh --issue -d www.priklad.cz -w /var/www/html \
        --reloadcmd "service apache2 force-reload"
  user@DebianVM:~$ acme.sh --issue -d www.priklad.cz -w /var/www/html
  [Pá pro 20 14:10:46 CET 2019] Creating domain key
  [Pá pro 20 14:10:46 CET 2019] The domain key is here: /home/user/.acme.sh/www.priklad.cz/www.priklad.cz.key
  [Pá pro 20 14:10:46 CET 2019] Multi domain='DNS:www.priklad.cz'
  [Pá pro 20 14:10:46 CET 2019] Getting domain auth token for each domain
  [Pá pro 20 14:10:55 CET 2019] Getting webroot for domain='www.priklad.cz'
  [Pá pro 20 14:10:55 CET 2019] Verifying: www.priklad.cz
  [Pá pro 20 14:10:59 CET 2019] Success
  [Pá pro 20 14:11:24 CET 2019] Verify finished, start to sign.
  [Pá pro 20 14:11:24 CET 2019] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/...
  [Pá pro 20 14:11:25 CET 2019] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/...
  [Pá pro 20 14:11:26 CET 2019] Cert success.
  -----BEGIN CERTIFICATE-----
  MII...
  -----END CERTIFICATE-----
  [Pá pro 20 14:11:26 CET 2019] Your cert is in  /home/user/.acme.sh/www.priklad.cz/www.priklad.cz.cer
  [Pá pro 20 14:11:26 CET 2019] Your cert key is in  /home/user/.acme.sh/www.priklad.cz/www.priklad.cz.key
  [Pá pro 20 14:11:26 CET 2019] The intermediate CA cert is in  /home/user/.acme.sh/www.priklad.cz/ca.cer
  [Pá pro 20 14:11:26 CET 2019] And the full chain certs is there:  /home/user/.acme.sh/www.priklad.cz/fullchain.cer
  user@DebianVM:~$
        
Gratuluji, váš certifikát, privátní klíč a další soubory jsou nyní na cestách, které jsou uvedeny na posledních 4 řádcích výstupu. Nás budou zajímat soubory
fullchain.cer
a
<vaše_doména>.key
, ale k tomu až později. Certifikát by se zároveň měl vždy před vypršením obnovit, pokud vše bude fungovat. Zároveň se restartuje Apache, aby se obnovený certifkát vždy ihned použil (k tomu slouží argument
--reloadcmd
).
Ukazuje-li se nějaká chyba, tak zkontrolujte překlepy, práva k zápisu, špatně fungující redakční systémy apod., a pokud zde neuspějete, tak si prostě jen přečtěte, co se stalo špatně a pokuste se to vyřešit. Chyby jsou většinou vypisovány lidsky i s nějakými návrhy řešení (žádné nicneříkájící chybové kódy v šestnáctkové soustavě zde nečekejte). Nebo, ostatně jako vždy, zkuste pogooglit; žádnou chybu jako první na světě řešit nebudete.
Pro pokročilejší: skript je automaticky spouštěn démonem cron, aby docházelo k obnovení, je-li to potřeba. Pokud se chcete přesvědčit, že skript je ve cronu zanesen, spusťte příkaz
crontab -l
a jestliže ve výstupu najdete řádek s
acme.sh
, vše se správně nastavilo.
Tímto už bychom tu nejdůležitější část měli za sebou a nyní se můžeme přesunout na samotnou konfiguraci webserveru tak, aby byl certifikát používán.


2. Nastavení modulu ssl

Dobrá, certifikát máme, a co dál? Nejdříve zapneme a nastavíme modul ssl, aby nebyly používány protokoly a šifrovací sady, které dnes nejsou považovány za bezpečné.
Apache ve výchozím stavu nemá zapnutý modul ssl, který se stará o námi chtěné šifrování. Na povolování modulu je zde však jednoduchá utilitka a tak to nebude nic těžkého. Zapnutí spácháme spuštěním příkazu:
sudo a2enmod ssl
  user@DebianVM:~$ sudo a2enmod ssl
  Considering dependency setenvif for ssl:
  Module setenvif already enabled
  Considering dependency mime for ssl:
  Module mime already enabled
  Considering dependency socache_shmcb for ssl:
  Enabling module socache_shmcb.
  Enabling module ssl.
  See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
  To activate the new configuration, you need to run:
    systemctl restart apache2
  user@DebianVM:~$
        
Kýžený modul se nám aktivuje a utilitka nám správně říká, že bychom měli server restartovat. My to zatím dělat nemusíme, nicméně pokud jste to již udělali, ničemu to nevadí. Server bychom totiž zbytečně restartovali několikrát. Teď už se můžeme vrhnout na konfiguraci modulu ssl.
Pro pokročilejší: Aktivací HTTPS se vám zpřístupní možnost využití nového protokolu HTTP/2, který může zrychlit načítání stránek. Má to však jeden háček: nesmíte mít server s MPM prefork. To se mj. stává, když máte zaplý mod_php (a PHP nepoužíváte přes FastCGI). Vámi použitý MPM můžete rozpoznat např. příkazem
ls -lAh /etc/apache2/mods-enabled/mpm_*.load
Jste-li si jisti, že máte zaplý MPM event nebo worker, můžete modul aktivovat pomocí
sudo a2enmod http2
Modul ssl je dobré nakonfigurovat tak, aby používal pouze šifrovací sady a verze protokolu TLS, které se nedají považovat za nebezpečné. TLS je protokol, který "obalí" jakékoliv TCP spojení a šifruje v něm přenášená data, což z něho dělá základní kámen nejen HTTPS, ale i FTPS, IMAPS, POP3S, SMTPS, DNS over TLS, SSTP VPN a dalších. K šifrování používá TLS tzv. šifrovací sady (cipher suites), z nichž některé nejsou již úplně bezpečné, protože zastaraly vlivem dlouhého vývoje a používání. Těmto věcem však nemusíte rozumět; mám zde pro vás připravené útržky konfigurace, které bude stačit zkopírovat.
Otevřeme konfigurační souboru modulu ssl, který se nachází na /etc/apache2/mods-enabled/ssl.conf vašim oblíbeným editorem, pro začátečníky je vhodný a v Debianu předinstalovaný např. nano:
sudo nano /etc/apache2/mods-enabled/ssl.conf
... a sescrollujeme někam níž, kde uvidíme něco podobného níže uvedené ukázce. Našim úkolem bude zakomentovat (tzn. na začátek dát znak křížku #) řádky, které začínají na SSLCipherSuite, SSLHonorCipherOrder, SSLProtocol a SSLInsecureNegotiation (některé už zakomentované být můžou). Mělo by to vypadat tedy nějak takto:
  ...
  #   Configure the path to the mutual exclusion semaphore the
  #   SSL engine uses internally for inter-process synchronization.
  #   (Disabled by default, the global Mutex directive consolidates by default
  #   this)
  #Mutex file:${APACHE_LOCK_DIR}/ssl_mutex ssl-cache

  #   SSL Cipher Suite:
  #   List the ciphers that the client is permitted to negotiate. See the
  #   ciphers(1) man page from the openssl package for list of all available
  #   options.
  #   Enable only secure ciphers:
  #SSLCipherSuite HIGH:!aNULL

  # SSL server cipher order preference:
  # Use server priorities for cipher algorithm choice.
  # Clients may prefer lower grade encryption.  You should enable this
  # option if you want to enforce stronger encryption, and can afford
  # the CPU cost, and did not override SSLCipherSuite in a way that puts
  # insecure ciphers first.
  # Default: Off
  #SSLHonorCipherOrder on

  #   The protocols to enable.
  #   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
  #   SSL v2  is no longer supported
  #SSLProtocol all -SSLv3

  #   Allow insecure renegotiation with clients which do not yet support the
  #   secure renegotiation protocol. Default: Off
  #SSLInsecureRenegotiation on

  #   Whether to forbid non-SNI clients to access name based virtual hosts.
  #   Default: Off
  #SSLStrictSNIVHostCheck On

  </IfModule>
  ...
        
Tím bychom měli zakázané ne uplně vhodné možnosti výchozí konfigurace a pokud to nechcete řešit nějak do hloubky, tak nad direktivu </IfModule> pouze zkopírujte následující červeně vyznačený útržek tak, aby konfigurace byla podobná této:
  ...
  #   Whether to forbid non-SNI clients to access name based virtual hosts.
  #   Default: Off
  #SSLStrictSNIVHostCheck On

  SSLProtocol         all -SSLv3
  SSLCipherSuite      ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384::ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA
  SSLHonorCipherOrder on
  SSLSessionTickets   off

  </IfModule>
  ...
        
Soubor nyní uložíme (v nano je to klávesovou zkratkou Ctrl + O a poté Enter) a editor ukončíme (Ctrl + X). Tímto bychom byli s konfigurací modulu ssl hotovi. Nyní můžeme přejít k nasazení samotného certifikátu a zapnutí protokolu HTTPS.
Pozn.: S těmito šifrovacími sadami nebudou fungovat extrémně staří klienti jako Android 2.3 nebo Internet Explorer na Windows XP a starší. Takových klientů již po webu chodí naprosto zanedbatelné minimum (ono se jim totiž moc stránek už dnes správně nezobrazí), jak říká např. NetMarketShare a není potřeba se jimi zaobírat. Pokud je opravdu nutně potřebujete, tak ponechte výchozí konfiguraci s tím, že odkomentujete řádek SSLHonorCipherOrder on. Píšu to sem v podstatě jen proto, aby mi potom nikdo nic neházel na hlavu. Byli jste varováni.
Pro pokročilejší: Pokud jste v tomto tématu trochu zběhlejší, možná si říkáte, proč zde, v roce 2020, nevypínám TLS 1.0 a 1.1. Důvod to má takový, že klienti s Android 4.1 či 4.2 se (bohužel) ještě nějací najdou (jak dokládá výše zmiňovaný NetMarketShare i jiné statistiky podobného rázu). Tito zrovna TLS 1.2 nepodporují. Pokud si chcete vygenerovat konfiguraci na míru, můžete použít Mozilla SSL Configuration Generator.


3. Nasazení certifikátu a samotné zprovoznění TLS

Nyní již konečně můžeme přejít k části, na kterou jste všichni čekali. Už se totiž budeme na náš web moci připojit pomocí HTTPS.
Mějme tedy opět výchozí konfiguraci, kdy je váš web poháněn tzv. virtuálním hostem (dále vhost), jehož definiční soubor se nachází na /etc/apache2/sites-available/000-default.conf. Vhost je používán Apachem i jinými web servery, aby mohlo být hostováno více webů na jedné IP adrese (zjednodušeně řečeno). Tento vhost musíme nyní "zdvojit", protože HTTPS a HTTP používají rozdílnou konfiguraci (oproti HTTP musí být ve vhostu pro HTTPS uvedeny certifikáty a klíče a naopak ve vhostu pro HTTP by mělo být přesměrování, ale k tomu až později).
Přejděme tedy do složky s vhosty a zkopírujeme ten náš např. následující dvojicí příkazů:
cd /etc/apache2/sites-available/
sudo cp 000-default.conf 000-default-https.conf
Nyní otevřeme nově zkopírovaný konfigurák např. editorem nano, podobným způsobem, jako jsme si ukazovali výše (tedy
sudo nano 000-default-https.conf
). V něm budeme muset ihned nahoře udělat dvě malé změny: budeme muset přepsat naslouchací port za 80 na 443 a přidat instrukce pro OpenSSL:
  <VirtualHost *:443>
      SSLEngine on
      SSLCertificateFile /home/user/.acme.sh/www.priklad.cz/fullchain.cer
      SSLCertificateKeyFile /home/user/.acme.sh/www.priklad.cz/www.priklad.cz.key

      # The ServerName directive sets the request scheme, hostname and port that
      # the server uses to identify itself. This is used when creating
      # redirection URLs. In the context of virtual hosts, the ServerName
      ...
        
Samozřejmě nezapomeneme přepsat cesty k certifikátu a privátnímu klíči našimi vlastními. Nuže a teď ještě vysvětlímě pojmy z předminulé věty: port je "číslo" používané hlavně u protokolů TCP a UDP, které umožňuje mít na jedné IP adrese spuštěno více služeb a OpenSSL je program, který se stará o šifrování protokolem TLS (starší verze TLS se jmenovaly SSL, tak proto ten název).
Po dokončení editace ukončíme editor (nano: Ctrl + O, Enter, Ctrl + X) a můžeme si nově vytvořeného vhosta povolit. To se dělá velice jednoduše:
sudo a2ensite 000-default-https
  user@DebianVM:/etc/apache2/sites-available$ sudo a2ensite 000-default-https
  Enabling site 000-default-https.
  To activate the new configuration, you need to run:
    systemctl reload apache2
  user@DebianVM:/etc/apache2/sites-available$
        
Gratuluji, máme většinu úkolu za námi. Nyní bychom ještě měli zprovoznit přesměrování na HTTPS.


4. Přesměrování z HTTP na HTTPS

HTTPS nám sice už úspěšně běží, nicméně všichni uživatelé budou chodit stále na nezabezpečenou verzi po HTTP, protože jsou na ni namířeny odkazy i vyhledávače a ono to přece funguje, tak to nemá nikdo potřebu měnit. K přechodu je tedy musíme donutit. Velice nenásilnou a automatickou formou je přesměrování. Uživatel nic nepozná a přece ho to (ve většině případů, viz. SSLStrip) ochrání. Není to nic složitého, takže pojďme na to.
Nejdříve musíme povolit Apache modul rewrite, který bude přesměrování zařizovat. Schválně zkuste hádat, jak se to bude dělat:
sudo a2enmod rewrite
  user@DebianVM:/etc/apache2/sites-available$ sudo a2enmod rewrite
  Enabling module rewrite.
  To activate the new configuration, you need to run:
    systemctl restart apache2
  user@DebianVM:/etc/apache2/sites-available$
        
Je dost možné, že modul budete mít již povolený; je to jeden z těch nejpoužívanějších. Ale nic neuškodí si to pro jistotu zkontrolovat. Jsme-li stále ve složkce s vhosty (/etc/apache2/sites-available/), tak otevřeme náš původní HTTP-only vhost s názvem 000-default.conf opět v nějakém editoru a v podstatě kamkoliv přidáme následující dva červeně vyznačené řádky; já je budu přidávat hned nahoru:
  <VirtualHost *:80>
      RewriteEngine On
      RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

      # The ServerName directive sets the request scheme, hostname and port that
      # the server uses to identify itself. This is used when creating
      # redirection URLs. In the context of virtual hosts, the ServerName
      ...
        
Na porozumění konfiguraci modulu rewrite je už potřeba znát trochu regulární výrazy apod., takže se vysvětlením nějak zaobírat nebudeme. Prostě to budeme brát jako hotovou věc. Nyní mohu s klidem říct, že jsme u konce. Teď už stačí jen restartovat webserver a vše by mělo běžet.


5. Restart serveru!

Nyní už nám bude stačit spustit jediný příkaz a vše by mělo fungovat:
sudo service apache2 restart
Webserver jste nyní restartovali. Pokud jste si to vyložili tak, že máte stroj fyzicky restarovat, ničemu to nevadí; efekt to bude mít stejný.
Ukázala-li se při restartu serveru nějaká chyba, tak vězte, že se to stává celkem běžně; překlepy hold stávají. Zkontrolujte si tedy, zda-li jste vše udělali tak, jak jste měli a zkuste server restartovat znovu. Pokud ani to nepomůže, tak Apache má záznam chybových i informativních hlášení v souboru /var/log/apache2/error.log. Soubor si tedy vypište (např. příkazem
cat /var/log/apache2/error.log
) a zkuste najít nějaký řádek (většinou bude někde vespod výstupu), který bude pro vás relevantní. Podle dotyčného hlášení se můžete chybu pokusit opravit a pokud si nebudete vědět rady, vždy zde platí, že Google ví všechno a nebudete první, kdo problém kdy řešil. Chvilka hledání nikdy neuškodí.
Tímto bychom měli práci dokončenou. Zkuste si schválně jít na vaše stránky a můžete se kochat tím, jak jsou zabezpečené. :-)
HTTPS už funguje :-)
Pozn.: Pokud jste si stránku prošli a přišli jste na to, že vám nefungují nějaké skripty, styly, obrázky apod., jedná se o problém tzv. mixed contentu neboli smíšeného obsahu. Vyřešit se to dá tak, že najdete na stránce veškeré absolutní odkazy (tzn. ty, jejichž href nebo src začíná na http://) a přepište u nich protokol na https://. Více se o tom můžete dozvědět napříkad zde nebo zde.



Tímto bychom byli u konce a váš web by měl být zabezpečený. Když se na to teď zpětně dívám, tak si skutečně říkám, že jsem to s tou délkou možná trošku přepísk, ale na druhou stranu si říkám, že, jak již bylo zmiňováno výše, teď už si nikdo nebude moct stěžovat, že přechod na HTTPS je pro něj moc těžký. Myslím si, že podle tohoto návodu by se mohl řídit i opičák. :-)
Je zde ještě pár věcí, které by mohly zabezpečení zlepšit, např. HSTS, nicméně si myslím, že k tomu návodu mířeného na začátečníky to úplně nepatří, protože pokud si tyto věci špatně nakonfigurujete, můžete si tím ten web i na pár měsíců znepřístupnit.