Certifikáty a TLS: jak zařídit HTTPS, které nevyprší

Nejrychleji přes bezplatný sken na této stránce: oblast „Certifikáty a šifrování“ ukáže, kolik dní zbývá do expirace, jestli certifikát platí pro vaši doménu a jakou verzí protokolu se server domluvil. V terminálu zjistíte totéž a ještě o kus víc:

openssl s_client -connect vase-firma.cz:443 -servername vase-firma.cz </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Pusťte to na víc adresách než na jedné. Kromě hlavní domény určitě na variantu s www, na API i na subdomény, které vám vypsal sken. Každá z nich může mít vlastní certifikát, vlastní server a vlastní datum expirace.

Cíl je jediný: nikdy už na certifikát nesahat rukou. Vyberte si cestu podle toho, kde web běží.

Vlastní server s nginxem nebo Apachem. Standardem je certbot, který certifikát vystaví i zapíše do konfigurace sám:

sudo certbot --nginx -d vase-firma.cz -d www.vase-firma.cz

Caddy. Nedělá se nic. Certifikát si vystaví i obnovuje sám od začátku, stačí mít v konfiguraci správný název domény a otevřené porty 80 a 443.

Sdílený hosting nebo administrace poskytovatele. Hledejte v panelu položku „SSL“ nebo „Certifikáty“ a přepínač automatické obnovy. Bývá vypnutý u domén, které se na hosting přidaly později. Zaškrtněte ho u každé domény i subdomény zvlášť, hromadně to obvykle nejde.

Web za CDN nebo proxy. Tam je potřeba myslet na dva certifikáty, ne na jeden: ten veřejný na straně CDN a ten na vašem serveru, kam CDN sahá. Certifikát na serveru vidíte v prohlížeči i ve skenu jen tehdy, když se zeptáte na přímou adresu, a právě proto se na něj zapomíná nejčastěji.

Potřebujete-li pokrýt certifikátem všechny subdomény najednou (*.vase-firma.cz), počítejte s tím, že se vystavuje přes DNS záznam, ne přes soubor na webu — certbot k tomu potřebuje plugin na vašeho DNS poskytovatele a API token. U pěti známých subdomén je jednodušší vypsat je za -d.

Tohle je ten krok, který se přeskakuje, a přitom právě on dělá rozdíl mezi automatizací a její iluzí. Nejčastější příčina propadlého certifikátu totiž není zapomenutá obnova, ale obnova, po které nikdo nepřenačetl webserver: nový soubor leží na disku, jenže nginx posílá pořád ten starý, který si načetl při startu.

sudo certbot renew --dry-run
systemctl list-timers | grep certbot

Reload po obnově se zařídí jednou provždy hookem. Certbot spouští po každé úspěšné obnově všechno, co najde ve složce /etc/letsencrypt/renewal-hooks/deploy/:

#!/bin/sh
systemctl reload nginx

Zkoušku nadvakrát uděláte příkazem sudo certbot renew --force-renewal a hned poté prvním příkazem z kroku 1. Když se datum expirace posunulo i navenek, máte hotovo doopravdy.

Certifikát platí pro názvy vypsané ve svém subjectAltName, a pro žádné jiné. Projděte si výpis z prvního kroku a porovnejte ho se seznamem subdomén ze skenu. Typicky chybí:

• varianta s www (nebo naopak doména bez ní),
• subdomény, které vznikly později — api, eshop, kalendar,
• doména v jiné koncovce, kterou máte zaregistrovanou obranně a přesměrováváte ji,
• poštovní server, pokud klienti chodí na mail.vase-firma.cz.

Přesměrování problém neřeší. K přesměrování totiž dojde až po navázání šifrovaného spojení, takže varování v prohlížeči naskočí dřív, než se návštěvník stihne dostat na správnou adresu.

Server musí kromě vlastního certifikátu poslat i mezilehlý certifikát autority. Právě tenhle rozdíl je za většinou nálezů „certifikát není důvěryhodný“ a pozná se tím, že web funguje v Chromu na počítači, ale ne na telefonu nebo v curlu. V konfiguraci proto patří vždycky fullchain.pem, nikdy ne samotný cert.pem:

ssl_certificate     /etc/letsencrypt/live/vase-firma.cz/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vase-firma.cz/privkey.pem;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;

SSLEngine on
SSLCertificateFile    /etc/letsencrypt/live/vase-firma.cz/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/vase-firma.cz/privkey.pem

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

Ponechat TLS 1.2 a 1.3 je dnes bezpečná volba i pro zákazníky se starými zařízeními; návštěvníka, kterému by tohle nastavení web zavřelo, byste hledali dlouho. Výchozí sada šifer v obou serverech je v pořádku, vlastní seznam z nějakého deset let starého návodu bývá horší než žádný.

Ověření je jednoduché: v úplném výpisu openssl s_client se musí objevit řádek Verify return code: 0 (ok) a v seznamu poslaných certifikátů dva kusy, ne jeden.

Když certifikát sedí, zbývají dvě díry, kterými se ta šifrovaná cesta pořád dá obejít. První je web, který odpovídá i na http:// — to patří do návodu k bezpečnostním hlavičkám, kde je hotové přesměrování i HSTS. Druhá je smíšený obsah: stránka jede po HTTPS, ale obrázek, písmo nebo skript v ní míří na starou nešifrovanou adresu. Skripty prohlížeč rovnou zablokuje, takže se obvykle rozbije zrovna to, co vydělává.

curl -s https://vase-firma.cz | grep -oE 'http://[a-zA-Z0-9./_-]+' | sort -u

A nakonec hlídání. Let’s Encrypt od června 2025 e-maily o blížící se expiraci neposílá vůbec, takže se na ně nedá spoléhat ani jako na poslední záchranu. Hlídat to musí něco, co nezapomíná: monitoring, který jednou denně zkontroluje datum z certifikátu, nebo naše pravidelná kontrola, která vám blížící se expiraci vypíše v měsíčním reportu spolu se zbytkem změn.