9. HTTP/HTTPS, TLS/SSL certifikáty (Let's Encrypt)

Úvod a kontext

HTTP je protokol, na kterém stojí drtivá většina webových aplikací a
API, které DevOps inženýr provozuje. V dnešní praxi je navíc téměř
vždy vyžadována jeho zabezpečená varianta HTTPS — bez platného TLS
certifikátu prohlížeče web označí jako nedůvěryhodný, a řada moderních
API a integrací (platby, OAuth) HTTPS přímo vyžaduje. Tato lekce
vysvětlí, jak HTTP komunikace probíhá, jak funguje šifrování přes TLS a
jak v praxi získat a spravovat certifikát pomocí bezplatné autority
Let's Encrypt.

Teorie

Model požadavek-odpověď

HTTP (HyperText Transfer Protocol) je textový, bezstavový protokol
postavený na modelu požadavek → odpověď: klient (prohlížeč, curl,
jiná služba) odešle požadavek na server, server odpoví. Bezstavovost
znamená, že server si sám o sobě nepamatuje nic mezi jednotlivými
požadavky — stav (např. přihlášení uživatele) se řeší nad HTTP pomocí
cookies, tokenů apod.

Struktura požadavku:

GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...

Struktura odpovědi:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 128

{"id": 42, "name": "Petr"}

HTTP metody a stavové kódy

Nejběžnější metody: GET (čtení dat, nemá měnit stav), POST
(vytvoření/odeslání dat), PUT/PATCH (aktualizace), DELETE
(smazání). Stavové kódy se dělí do skupin podle první číslice:

• 1xx — informační (zřídka viditelné, např. 101 Switching Protocols).
• 2xx — úspěch (200 OK, 201 Created, 204 No Content).
• 3xx — přesměrování (301 Moved Permanently, 302 Found,
  304 Not Modified — obsah se od poslední žádosti nezměnil, klient
  může použít vlastní cache).
• 4xx — chyba na straně klienta (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).
• 5xx — chyba na straně serveru (500 Internal Server Error,
  502 Bad Gateway — typicky reverzní proxy nedostala odpověď od
  backendu, 503 Service Unavailable, 504 Gateway Timeout).

Rozlišení mezi 4xx a 5xx je pro DevOps zásadní diagnostický signál:
4xx obvykle znamená problém v požadavku klienta nebo v jeho
oprávnění, 5xx znamená, že se něco pokazilo na serveru/backendu a je
potřeba se dívat do logů aplikace.

Proč HTTPS: šifrování, integrita, autenticita

Čisté HTTP posílá data v otevřeném textu — kdokoliv na cestě mezi
klientem a serverem (například na nezabezpečené Wi-Fi) je může číst
nebo měnit. HTTPS = HTTP přenášené přes TLS (Transport Layer
Security, nástupce staršího SSL), který řeší tři věci najednou:

1. Šifrování — obsah komunikace nelze odposlechnout.
2. Integrita — nelze ho nepozorovaně změnit cestou.
3. Autenticita — klient si může ověřit, že komunikuje se skutečným
   serverem example.com, a ne s útočníkem (man-in-the-middle).

Jak funguje TLS handshake (zjednodušeně)

1. Klient se připojí a pošle serveru seznam podporovaných šifrovacích
   algoritmů (ClientHello).
2. Server odpoví vybraným algoritmem a pošle svůj certifikát, který
   obsahuje jeho veřejný klíč a je podepsaný certifikační autoritou
   (CA).
3. Klient certifikát ověří proti seznamu důvěryhodných CA (uložených v
   prohlížeči/OS) — zkontroluje platnost, doménové jméno a podpis.
4. Klient a server si pomocí asymetrické kryptografie bezpečně
   domluví sdílený session key (symetrický klíč).
5. Od té chvíle probíhá veškerá komunikace šifrovaná symetricky tímto
   klíčem — je to rychlejší než asymetrické šifrování všech dat.

Certifikáty a certifikační autority

Certifikát je digitálně podepsané potvrzení, že daný veřejný klíč patří
danému doménovému jménu. Vydávají je certifikační autority (CA) —
důvěryhodné třetí strany, jejichž kořenové certifikáty jsou
předinstalované v operačních systémech a prohlížečích. Pokud prohlížeč
nedokáže sestavit důvěryhodný řetězec od certifikátu webu až ke
kořenové CA, zobrazí varování.

Let's Encrypt je bezplatná, automatizovaná CA (provozovaná
neziskovou organizací ISRG), která od roku 2016 zásadně zjednodušila
zabezpečení webu — dřív se certifikáty kupovaly ročně a instalovaly
ručně, dnes je lze získat a automaticky obnovovat zdarma pomocí
protokolu ACME (Automatic Certificate Management Environment).
Certifikáty Let's Encrypt platí 90 dní a jsou navrženy tak, aby se
automaticky obnovovaly ještě dřív, než vyprší.

Praktický příklad

Nejběžnější klient pro ACME protokol je Certbot. Vystavení
certifikátu pro doménu obsluhovanou Nginxem (Certbot automaticky upraví
i konfiguraci Nginxu):

$ sudo apt install certbot python3-certbot-nginx
$ sudo certbot --nginx -d example.com -d www.example.com

Successfully received certificate.
Certificate is saved at:
  /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:
  /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-12-15.

Certbot přidá do konfigurace Nginxu direktivy pro TLS:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;
    }
}

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;   # trvalé přesměrování na HTTPS
}

Automatická obnova (Certbot si standardně nastaví vlastní systemd
timer, ale je dobré ji ověřit a případně nasimulovat):

$ sudo systemctl list-timers | grep certbot
certbot.timer   ... certbot.service

$ sudo certbot renew --dry-run
Congratulations, all simulated renewals succeeded

Ověření certifikátu z příkazové řádky pomocí curl a openssl:

$ curl -vI https://example.com 2>&1 | grep -E "SSL|subject|expire"
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
*  subject: CN=example.com
*  expire date: Dec 15 12:00:00 2026 GMT

$ echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
    | openssl x509 -noout -dates
notBefore=Sep 16 12:00:00 2026 GMT
notAfter=Dec 15 12:00:00 2026 GMT

Shrnutí

HTTP je bezstavový protokol požadavek-odpověď se standardizovanými
metodami a stavovými kódy, kde první číslice kódu (2xx/3xx/4xx/5xx)
napovídá, na které straně (klient/server) problém nastal. HTTPS
přidává vrstvu TLS, která šifruje, chrání integritu a ověřuje
autenticitu serveru pomocí certifikátů vydaných certifikačními
autoritami. Let's Encrypt spolu s nástrojem Certbot umožňuje zdarma a
automatizovaně vystavovat i obnovovat certifikáty pomocí protokolu
ACME, což je dnes standardní praxe pro zabezpečení produkčních webů.

Kontrolní otázky

1. Co znamená, že HTTP je "bezstavový" protokol, a jak se přesto řeší
   přihlašování uživatelů?
2. Vysvětlete rozdíl mezi stavovým kódem 404 a 502 — na které
   straně (klient/server) je pravděpodobně chyba a proč?
3. Jaké tři vlastnosti komunikace zajišťuje TLS?
4. Co je certifikační autorita a proč prohlížeč důvěřuje certifikátu
   vydanému Let's Encrypt?