SSL/TLS od A do Z – kompletní průvodce

Malý zámek v adresním řádku prohlížeče. Čtyři písmena HTTPS místo HTTP. Zdánlivá banalita, na níž stojí veškerá důvěra moderního internetu — od internetového bankovnictví přes e-shopy po firemní VPN. Tento průvodce vás provede od toho, co ten zámek vlastně znamená, přes TLS handshake a certifikační autority až po mTLS, certificate pinning a diagnostiku příkazovou řádkou.

Co je ten zámek v prohlížeči — a proč na něm záleží

Než se ponoříme do techniky, začněme tím, co vidíte každý den. Když otevřete webovou stránku, v levé části adresního řádku se zobrazí malý zámek — nebo jeho absence. Co to znamená?

Zámek = šifrované spojení. Veškerá komunikace mezi vaším prohlížečem a serverem je zašifrovaná. Nikdo na cestě — váš ISP (poskytovatel internetu), operátor Wi-Fi kavárny, útočník v síti — nemůže číst obsah. Vidí jen to, s jakým serverem komunikujete (a ani to ne vždy, viz SNI níže), ale ne co si říkáte.

Zámek neznamená „tento web je bezpečný" nebo „tomuhle webu lze věřit". Phishingový web napodobující vaši banku může mít perfektně fungující HTTPS a zelený zámek. Šifrování říká pouze: „Komunikace je soukromá." Nic o tom, kdo je na druhé straně a zda jsou v pořádku.

Co se šifruje a co ne

Šifruje se obsah stránky, odesílaná data (hesla, formuláře, čísla platebních karet), HTTP hlavičky a cookies. Nešifruje se doménové jméno, na které se připojujete — to je vidět z DNS dotazu (pokud nepoužíváte DoH/DoT, viz průvodce DNS) a také ze SNI pole v TLS handshake — k tomu se dostaneme níže v článku.

Jak poznat problém s certifikátem

Prohlížeče zobrazují různá varování podle závažnosti:

• Červená stránka „Vaše připojení není soukromé" — certifikát je neplatný, prošlý, podepsaný nedůvěryhodnou certifikační autoritou (CA — organizace, která certifikáty vydává a ručí za jejich pravost), nebo doménové jméno neodpovídá. Tady opravdu nezadávejte žádné citlivé údaje a odejděte.
• Žlutý trojúhelník (smíšený obsah) — stránka je načtena přes HTTPS, ale načítá některé zdroje (obrázky, skripty) přes HTTP. Šifrování celé stránky je tím oslabeno.
• „Certifikát není důvěryhodný" — nejčastěji jde o certifikát podepsaný samotným serverem (tzv. self-signed: server si ho vystavil sám, žádná třetí strana za něj neručí) nebo certifikát vydaný interní firemní autoritou, kterou váš domácí počítač nezná. Ve firemním prostředí je to normální a IT to ví. Na veřejném webu jde o problém.

Terminologický chaos: SSL, TLS, HTTPS — co je co

Pravděpodobně nejčastější zdroj zmatku: lidé říkají „SSL certifikát", „SSL/TLS", nebo jen „SSL" — a myslí tím věc, která se dnes jmenuje TLS. Pojďme si to jednou provždy ujasnit.

Historická linie

SSL (Secure Sockets Layer) vznikl v Netscape v polovině 90. let:

• SSL 1.0 — nikdy nevyšel veřejně (závažné chyby)
• SSL 2.0 (1995) — první veřejná verze, dnes zakázána (RFC 6176)
• SSL 3.0 (1996) — vydržel dlouho, ale v roce 2014 ho zabila zranitelnost POODLE. Dnes zakázán (RFC 7568)

TLS (Transport Layer Security) je nástupce SSL, vyvíjený pod záštitou IETF:

• TLS 1.0 (1999) — de facto přejmenovaný SSL 3.1, v roce 2021 označen jako zastaralý (RFC 8996), PCI DSS (mezinárodní bezpečnostní standard pro platební karty) ho zakázal
• TLS 1.1 (2006) — malá vylepšení, stejně zastaralý
• TLS 1.2 (2008) — stále běžně používaný, bude ještě dlouho
• TLS 1.3 (2018) — aktuální standard, výrazně přepracovaný

HTTPS není samostatný protokol. Je to jednoduše HTTP běžící uvnitř TLS tunelu. Vzorec: HTTPS = HTTP + TLS. Stejně funguje SMTPS (e-mail), FTPS (soubory) nebo LDAPS (adresářové služby) — všechno jsou to aplikační protokoly zabezpečené přes TLS.

Kryptografie pod kapotou

Aby dávalo TLS smysl, potřebujete rozumět třem stavebním kamenům kryptografie. Žádná vyšší matematika — jen principy.

Symetrická kryptografie — rychlá, ale s problémem

Symetrická kryptografie používá jeden klíč pro šifrování i dešifrování. Odesilatel i příjemce musejí mít stejný klíč. Je to rychlé a efektivní — moderní algoritmy jako AES šifrují gigabajty dat za sekundu.

Problém: jak ten klíč bezpečně předat? Pokud ho pošlete po internetu nešifrovaně, kdokoli na cestě ho zachytí. Pošleme si klíč osobně? Na internetu to nejde. Tenhle problém řešil svět desítky let — a odpovědí je asymetrická kryptografie.

Asymetrická kryptografie — řeší výměnu klíčů

Asymetrická kryptografie pracuje s dvojicí klíčů: veřejným a soukromým. Co zašifruje jeden, rozšifruje druhý. Soukromý klíč nikdy neopouští server. Veřejný klíč může znát celý svět.

Analogie: představte si poštovní schránku s otvorem. Kdokoli může vhodit zprávu (zašifrovat veřejným klíčem), ale otevřít zámek a vyndat zprávy může jen majitel se soukromým klíčem.

Nevýhoda: asymetrická kryptografie je řádově pomalejší než symetrická. Proto se v TLS nepoužívá na šifrování dat — používá se pouze na bezpečnou výměnu symetrického klíče. Data pak jdou symetricky. Nejpoužívanější algoritmy: RSA (starší, stále rozšířený), ECDSA a ECDH (modernější, kratší klíče, rychlejší).

Hašovací funkce a integrita dat

Hašovací funkce vezme libovolně dlouhý vstup a vrátí pevně dlouhý „otisk" (hash). SHA-256 vždy vrátí 256 bitů. Klíčová vlastnost: i minimální změna vstupu zcela změní výstup, a z hashe nelze zpětně rekonstruovat vstup.

V TLS se hašovací funkce používají v kombinaci s klíčem jako HMAC (Hash-based Message Authentication Code) — ověřují, že data nebyla po cestě pozměněna. Každá zpráva v TLS přenáší MAC, příjemce ho ověří.

Jak TLS kombinuje oboje

Shrnutí principu: asymetrická kryptografie se použije jednou na začátku spojení k dohodnutí sdíleného tajemství (session key). Tím se obejde problém s výměnou klíčů. Pak se přejde na symetrické šifrování — rychlé a efektivní — pro veškerá přenášená data. Hašovací funkce průběžně ověřují integritu.

TLS handshake krok za krokem

Handshake je úvodní „podání ruky" — prohlížeč a server se dohodnou, co budou používat, ověří totožnost serveru a vymění si klíče. Vše se stane ještě předtím, než se přenese jediný bajt vaší stránky.

TLS 1.2 handshake

TLS 1.2 potřebuje 2 round-tripy (RTT) — dvě cesty tam a zpět — než začne přenos dat. U spojení s latencí 50 ms to přidá 100–200 ms overhead jen na handshake.

1. ClientHello — klient pošle: podporované verze TLS, náhodné číslo (client random), seznam podporovaných cipher suites (sad kryptografických algoritmů — vysvětlíme níže) a rozšíření jako SNI
2. ServerHello — server vybere verzi TLS a cipher suite, pošle své náhodné číslo (server random)
3. Certificate — server pošle svůj certifikát (nebo celý řetěz certifikátů)
4. ServerKeyExchange — (jen u některých cipher suites) server pošle parametry pro výměnu klíčů
5. ServerHelloDone — server oznámí, že svou část dokončil
6. ClientKeyExchange — klient pošle svůj příspěvek k výměně klíčů. Z client random + server random + výsledku výměny klíčů se odvodí master secret (hlavní sdílené tajemství), z něhož se dále odvodí session keys (šifrovací klíče pro toto konkrétní spojení)
7. ChangeCipherSpec + Finished (klient) — od teď šifrujeme, tady je potvrzení
8. ChangeCipherSpec + Finished (server) — potvrzení ze strany serveru

Teprve teď začíná přenos aplikačních dat.

TLS 1.3 handshake — rychlejší a bezpečnější

TLS 1.3 zredukoval handshake na 1 round-trip a zároveň vyřadil všechny zastaralé a nebezpečné součásti. Jak?

Klient v ClientHello rovnou odhadne, jaký key exchange algoritmus server preferuje, a pošle svůj klíčový příspěvek hned v prvním paketu. Server odpoví certifikátem a Finished v jednom kole — a data mohou začít téct.

Navíc TLS 1.3 podporuje 0-RTT (zero round-trip time) resumption: pokud se klient s tímto serverem v minulosti spojoval, může poslat aplikační data hned v prvním paketu, bez čekání na handshake. Má to však bezpečnostní kompromis: 0-RTT data jsou zranitelná na replay útok, proto se pro ně nesmějí používat nepostihnutelné operace (platby, nevratné akce).

PKI, certifikáty a chain of trust

Šifrování samotné nestačí. Potřebujete vědět, s kým šifrujete. Co vám brání v tom, aby se někdo v síti tvářil jako vaše banka a šifroval s vámi spojení? Tady vstupuje PKI — infrastruktura veřejného klíče.

Co je certifikát X.509

Certifikát je digitální dokument (standardizovaný jako X.509), který říká: „Tento veřejný klíč patří tomuto subjektu." Obsahuje:

• Subject — komu certifikát patří (doménové jméno, organizace)
• Issuer — kdo certifikát vydal (certifikační autorita)
• Subject Alternative Names (SANs) — seznam domén, pro které certifikát platí
• Veřejný klíč — pro ověření podpisu a šifrování
• Platnost — od kdy do kdy (NotBefore, NotAfter)
• Podpis CA — digitální podpis vydávající CA, který vše výše stvrzuje
• Serial number, fingerprint — identifikátory pro správu a revokaci

Chain of trust — řetěz důvěry

Prohlížeč nemůže znát certifikáty všech webů na světě. Místo toho důvěřuje hrstce kořenových certifikačních autorit (Root CA) — jejich certifikáty jsou předinstalované v operačním systému nebo prohlížeči (trust store). Na Windows je to systémové úložiště certifikátů, na macOS Keychain, v Linuxu balíček ca-certificates, Firefox má vlastní trust store.

Řetěz funguje takto:

1. Root CA podepíše certifikát Intermediate CA (mezivrstvová CA)
2. Intermediate CA podepíše certifikát vašeho webu (leaf certificate)
3. Prohlížeč ověří podpis leaf certifikátu pomocí Intermediate CA, pak podpis Intermediate CA pomocí Root CA, a Root CA najde ve svém trust store — hotovo

Proč ta mezilehlá CA? Root CA klíč je extrémně cenný — jeho kompromitace by zničila důvěru celého internetu. Proto Root CA bývá offline (fyzicky odpojená, v trezoru) a v praxi podepisuje jen Intermediate CA. Intermediate CA pak vydává certifikáty koncovým zákazníkům.

Jak prohlížeč ověřuje certifikát

Při každém HTTPS spojení prohlížeč:

1. Ověří, že doménové jméno odpovídá záznamu v certifikátu — konkrétně Common Name (CN) nebo Subject Alternative Names (SAN)
2. Ověří, že certifikát nepřekročil datum expirace
3. Sestaví řetěz od leaf certifikátu až po Root CA v trust store a ověří každý podpis
4. Zkontroluje, zda certifikát nebyl odvolán (OCSP nebo CRL)
5. Pokud vše sedí: zelený zámek. Pokud ne: varování nebo blokace

Typy certifikátů

Podle úrovně ověření

Pro většinu webů dnes stačí DV certifikát — Let's Encrypt ho vydá zdarma za sekundy. OV/EV certifikáty mají smysl, když záleží na tom, aby v detailu certifikátu bylo vidět jméno firmy.

Wildcard vs. SAN certifikáty

Wildcard certifikát pokrývá všechny subdomény jedné úrovně: *.naseit.cz platí pro www.naseit.cz, mail.naseit.cz, vpn.naseit.cz — ale ne pro sub.vpn.naseit.cz (dvě úrovně). Jeden certifikát pro celou doménu.

SAN (Subject Alternative Names) certifikát může pokrývat libovolný seznam domén: naseit.cz, www.naseit.cz, naseit.eu — i různé domény v jednom certifikátu. Let's Encrypt vydává SAN certifikáty pro až 100 domén najednou.

Praktická volba: wildcard je pohodlný pro subdomény jedné domény. SAN je flexibilnější, ale musíte explicitně uvést každou doménu — a při přidání nové subdomény obnovit certifikát.

Self-signed certifikáty

Self-signed certifikát si podepíše sám sobě vydavatel i příjemce v jednom — není vydán žádnou CA. Prohlížeče mu nevěří a zobrazí varování.

Kdy self-signed dává smysl: interní servery (monitorovací nástroje, admin rozhraní), vývojové prostředí, komunikace stroj-stroj kde obě strany certifikát explicitně důvěřují, nebo jako základ interní CA v podnikové infrastruktuře — kde si nasadíte vlastní Root CA a distribuujete ji na firemní zařízení.

Kdy self-signed nedává smysl: jakýkoli veřejně dostupný web. Uživatelé uvidí varování a odejdou — nebo hůř, naučí se ho ignorovat.

Let's Encrypt a ACME protokol

Před rokem 2015 stál DV certifikát desítky dolarů ročně a vyžadoval manuální proces. Let's Encrypt to změnil: DV certifikáty zdarma, automaticky, v řádu sekund. Dnes pokrývá stovky milionů webů.

Jak ACME funguje

ACME (Automatic Certificate Management Environment, RFC 8555) je protokol, který definuje, jak si klient automaticky vyžádá a obnoví certifikát. Princip je prostý: musíte CA prokázat, že kontrolujete doménu, pro kterou certifikát chcete.

Existují tři typy výzev (challenges):

HTTP-01 — ACME klient umístí specifický soubor na cestu http://vas-web.cz/.well-known/acme-challenge/TOKEN. CA si ho vyžádá a ověří. Jednoduchý, funguje pro 80 % případů. Nevýhoda: web musí být dostupný z internetu na portu 80.

DNS-01 — ACME klient přidá TXT záznam do DNS zóny vaší domény. CA ho zkontroluje. Výhoda: funguje i pro interní servery, wildcard certifikáty (HTTP-01 wildcard neumožňuje) a servery nepřístupné z internetu. Nevýhoda: vyžaduje API přístup k DNS poskytovateli.

TLS-ALPN-01 — validace přes TLS na portu 443. Méně běžné, hodí se pro specifické případy (load balancery, kde port 80 není k dispozici).

Certbot a automatická obnova

Nejrozšířenější ACME klient je Certbot. Certifikáty Let's Encrypt jsou platné 90 dní — záměrně krátce, aby se motivovalo k automatické obnově a minimalizovalo okno pro zneužití kompromitovaného certifikátu.

# Vydání certifikátu pro Nginx
certbot --nginx -d vas-web.cz -d www.vas-web.cz

# Vydání wildcard přes DNS-01 (vyžaduje plugin pro DNS providera)
certbot certonly --dns-cloudflare -d vas-web.cz -d *.vas-web.cz

# Ruční obnova
certbot renew

# Test obnovy (dry run)
certbot renew --dry-run

Certbot při instalaci automaticky přidá systemd timer nebo cron job pro obnovu. Certifikát se obnoví, pokud mu zbývá méně než 30 dní platnosti — takže ve skutečnosti běží 60 dní a obnovu máte s 30denním polštářem.

TLS 1.2 vs. TLS 1.3 — co konkrétně změnilo

TLS 1.3 přišel v roce 2018 po letech vývoje a je radikálnější změnou než jakákoli předchozí verze. Co konkrétně přinesl?

Vyřazené funkce v TLS 1.3

TLS 1.3 vyřadil celou řadu algoritmů a funkcí, které se ukázaly jako nebezpečné nebo zbytečné:

• RSA key transport (nahrazen ECDHE — důvod viz forward secrecy níže)
• RC4, DES, 3DES, MD5, SHA-1 pro HMAC
• Komprese (zranitelnost CRIME)
• Renegociace
• Všechny CBC mode cipher suites
• Export-grade kryptografie (historické pozůstatky z dob US exportní regulace)

Forward Secrecy jako default

Forward secrecy (FS), někdy také Perfect Forward Secrecy (PFS), je vlastnost, která zajišťuje, že kompromitace serverového soukromého klíče v budoucnosti neumožní dešifrovat dříve zachycená spojení.

Jak? Místo toho, aby se session key odvozoval přímo ze soukromého klíče serveru (jako v RSA key transport), každé spojení si vygeneruje efemérní (dočasné) klíče pomocí ECDHE — Elliptic Curve Diffie-Hellman Ephemeral. Ty existují jen po dobu spojení a pak jsou zahozeny. I kdyby útočník zachytil veškerý šifrovaný provoz a za rok získal soukromý klíč serveru — nedokáže zpětně nic dešifrovat.

TLS 1.2 forward secrecy podporoval, ale nebylo povinné. TLS 1.3 ho udělal jedinou možností.

AEAD — šifrování a autentizace v jednom

TLS 1.2 odděloval šifrování (confidentiality) od autentizace zpráv (integrity). Tato kombinace CBC + MAC vedla k celé řadě útoků (BEAST, Lucky13, POODLE). TLS 1.3 vyžaduje výhradně AEAD (Authenticated Encryption with Associated Data) algoritmy — v praxi AES-GCM nebo ChaCha20-Poly1305. Tyto algoritmy šifrují a autentizují zároveň, bez možnosti je oddělit.

Cipher suites — jak je číst a vybrat

Cipher suite je sada algoritmů, na které se klient se serverem dohodnou během handshake. Diktuje, co se použije pro výměnu klíčů, autentizaci, šifrování a integritu.

Anatomie názvu cipher suite (TLS 1.2)

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 |    |     |        |    |   |   |
 |    |     |        |    |   |   +-- Hash pro HMAC/PRF (SHA-384)
 |    |     |        |    |   +------ Šifrovací mód (GCM = AEAD)
 |    |     |        |    +---------- Délka klíče AES (256 bit)
 |    |     |        +--------------- Šifrovací algoritmus (AES)
 |    |     +------------------------ Autentizační algoritmus (RSA certifikát)
 |    +------------------------------ Výměna klíčů (ECDHE = forward secrecy)
 +----------------------------------- Protokol

V TLS 1.3 jsou cipher suites zjednodušeny — výměna klíčů a autentizace jsou odděleny, takže zbývá jen šifrovací algoritmus a hash:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Doporučená konfigurace pro produkci

Dobrým výchozím bodem je Mozilla SSL Configuration Generator. Profil „Intermediate" pokrývá moderní klienty a zároveň neblokuje starší systémy (Windows 7, Android 5+):

# Nginx — Intermediate profil
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

OCSP a OCSP Stapling — ověřování platnosti v reálném čase

Certifikát může být odvolán před uplynutím platnosti — třeba při kompromitaci soukromého klíče nebo chybě v procesu vydání. Prohlížeč potřebuje vědět, zda certifikát stále platí.

CRL (Certificate Revocation List) — historická metoda. CA publikuje seznam sériových čísel odvolaných certifikátů. Prohlížeče ho stahují, ale soubory jsou velké a obnova pomalá.

OCSP (Online Certificate Status Protocol) — prohlížeč se v reálném čase zeptá OCSP responderu CA: „Je certifikát s tímto sériovým číslem platný?" Odpověď: good / revoked / unknown. Rychlejší než CRL, ale přidává latenci ke každému TLS handshake a prozrazuje CA, jaké weby navštěvujete.

OCSP Stapling — elegantní řešení. Server sám pravidelně dotazuje OCSP responder CA a výsledek (podepsaný CA) přikládá přímo do TLS handshake. Prohlížeč nemusí kontaktovat CA — dostane OCSP odpověď od serveru. Rychlejší, soukromější, a funguje i když je OCSP responder CA dočasně nedostupný.

# Nginx — OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 1.1.1.1 valid=300s;
resolver_timeout 5s;

Certificate Transparency — veřejný audit vydaných certifikátů

Po kauzách jako DigiNotar vznikl požadavek: všechny vydané certifikáty musejí být veřejně zaznamenány v CT (Certificate Transparency) logu — append-only, kryptograficky auditovatelné databázi. Od roku 2018 Chrome vyžaduje, aby každý certifikát byl zaznamenán v alespoň dvou CT logu.

Co to přináší v praxi:

• Kdokoli může monitorovat, zda pro jeho doménu nebyl vydán certifikát bez jeho vědomí — pomocí nástrojů jako crt.sh
• Falešně vydané certifikáty jsou rychle odhaleny
• CA, které nedodržují pravidla, jsou veřejně viditelné a mohou přijít o zařazení do trust stores

Pro správce: nastavte monitoring CT logů pro vaše domény — dostanete upozornění, kdykoli je vydán nový certifikát. To je jeden z nejlepších způsobů detekce kompromitace domény nebo DNS hijackingu.

SNI — jeden server, mnoho domén

SNI (Server Name Indication) řeší zdánlivě triviální problém: jak může jeden server (jedna IP adresa) hostovat desítky webů s různými certifikáty, přičemž TLS handshake probíhá před tím, než server ví, na který web se klient ptá?

Bez SNI by server musel pro každý web mít samostatnou IP adresu — v éře IPv4 nepraktické. SNI přidává do ClientHello rozšíření s požadovaným hostname. Server přečte SNI, vybere správný certifikát a odpoví.

Bezpečnostně zajímavý aspekt: SNI je nešifrované (přichází před šifrovaným kanálem) — a to znamená, že hostname je viditelný i přes HTTPS. Váš ISP, firewall nebo kdokoli na cestě vidí, na jakou doménu se připojujete, i bez dešifrování obsahu.

Encrypted Client Hello (ECH), dříve ESNI, je novější standard, který SNI šifruje. Postupně se zavádí (Cloudflare, Firefox), ale zatím není všude podporován.

SNI je klíčové pro firewally s SSL inspekcí a pro DNS filtering — obojí pro identifikaci domény využívá právě nešifrované SNI pole. Úzce to souvisí i s kybernetickou bezpečností na perimetru sítě.

Certificate Pinning — a proč HPKP ztroskotalo

Certificate pinning je technika, kde aplikace odmítá přijmout jakýkoli certifikát kromě konkrétně předem definovaného (nebo certifikátu podepsaného konkrétní CA). Chrání před scénářem, kde útočník získá platný certifikát od kompromitované nebo zneužité CA.

V praxi se implementuje dvěma způsoby:

• Hardcoded v aplikaci — mobilní aplikace mají seznam otisků certifikátů přímo v kódu. Populární u bank a finančních institucí.
• HPKP (HTTP Public Key Pinning) — HTTP hlavička, která prohlížeči říkala, jaké klíče má pro danou doménu akceptovat. Deprecated a odstraněno z Chrome (2018) a Firefoxu (2020).

Proč HPKP ztroskotalo? Protože je to extrémně nebezpečná zbraň v nepovolaných rukou. Stačí chyba v konfiguraci, zapomenutý pin, nebo problémy při obnově certifikátu — a web se stane pro uživatele nedostupným na celou dobu platnosti pinu (až 60 dní). Několik webů se tím skutečně uzamklo pro všechny uživatele.

Dnes se místo HPKP doporučuje kombinace Certificate Transparency monitoringu a CAA DNS záznamů — záznamy v DNS, které omezují, které CA smějí vydávat certifikáty pro vaši doménu. Přidáte je v DNS správci a náklady jsou nulové:

naseit.cz.  IN  CAA  0 issue "letsencrypt.org"
naseit.cz.  IN  CAA  0 issuewild "letsencrypt.org"
naseit.cz.  IN  CAA  0 iodef "mailto:admin@naseit.cz"

mTLS — vzájemná autentizace

Standardní TLS autentizuje pouze server — klient ví, s kým mluví, ale server neví nic o klientovi (kromě IP adresy). mTLS (mutual TLS) přidává autentizaci v obou směrech: klient předkládá svůj vlastní certifikát a server ho ověří.

Typická použití:

• API autentizace — místo API klíčů nebo OAuth tokenů se klient prokáže certifikátem. Obtížnější k phishingu, protože privátní klíč nikdy neopouští klientský systém.
• Zero-trust architektura — v moderních zero-trust modelech každý service-to-service hovor používá mTLS. Žádná implicitní důvěra jen proto, že jste v interní síti.
• Service mesh — Kubernetes ekosystém (Istio, Linkerd) automaticky nasazuje mTLS mezi microservices. Správce infrastruktury tím dostane šifrování a autentizaci mezi službami bez změny kódu aplikace.
• VPN alternativy — moderní Zero Trust Network Access řešení používají mTLS pro ověření zařízení před přístupem do sítě

# Nginx — vyžadování klientského certifikátu
ssl_client_certificate /etc/nginx/client-ca.crt;
ssl_verify_client on;
ssl_verify_depth 2;

SSL inspection na firewallu

Firemní firewally a proxy servery někdy provádějí SSL inspection — hloubkovou analýzu šifrovaného provozu. V praxi jde o záměrný man-in-the-middle útok „pro dobrou věc": firewall dešifruje HTTPS provoz, analyzuje ho, a znovu zašifruje ke klientovi.

Jak to funguje: firewall má svou vlastní interní CA. Tuto CA přidáte do trust store na všech firemních zařízeních (přes Group Policy apod.). Když zaměstnanec navštíví https://github.com, firewall:

1. Naváže TLS spojení se skutečným serverem GitHub (ověří jeho certifikát)
2. Vydá klientovi nový certifikát pro github.com podepsaný interní CA
3. Čte veškerý provoz v plaintext a kontroluje ho na malware, zakázané weby (URL filtering) nebo únik citlivých dat (DLP — Data Loss Prevention)
4. Znovu zašifruje a přepošle ke klientovi

Z pohledu kybernetické bezpečnosti je SSL inspection mocný nástroj pro detekci malwaru v šifrovaném provozu. Zároveň je to kontroverzní záležitost — zaměstnavatel vidí obsah veškeré HTTPS komunikace zaměstnanců. Právní rámec (GDPR, zákoník práce) vyžaduje informovat zaměstnance o monitoringu.

Diagnostika — openssl a další nástroje

Správce serverů musí umět rychle zjistit, co certifikát říká, jakou verzi TLS server nabízí, a proč se připojení nedaří. Tady je praktický přehled.

openssl s_client

# Základní připojení a zobrazení informací o certifikátu
openssl s_client -connect naseit.cz:443

# Zobrazení celého řetězu certifikátů
openssl s_client -connect naseit.cz:443 -showcerts

# Vynutit konkrétní verzi TLS
openssl s_client -connect naseit.cz:443 -tls1_2
openssl s_client -connect naseit.cz:443 -tls1_3

# Zobrazit jen informace o certifikátu (bez interaktivního vstupu)
echo | openssl s_client -connect naseit.cz:443 2>/dev/null | openssl x509 -noout -text

# Zobrazit datum expirace
echo | openssl s_client -connect naseit.cz:443 2>/dev/null | openssl x509 -noout -dates

# Testovat konkrétní hostname za SNI (např. shared hosting)
openssl s_client -connect 1.2.3.4:443 -servername naseit.cz

# Ověřit OCSP stapling
openssl s_client -connect naseit.cz:443 -status 2>/dev/null | grep -A 6 "OCSP Response"

Dekódování certifikátu ze souboru

# Zobrazit obsah .crt nebo .pem souboru
openssl x509 -in certifikat.crt -noout -text

# Jen expiraci
openssl x509 -in certifikat.crt -noout -dates

# Jen subject a issuer
openssl x509 -in certifikat.crt -noout -subject -issuer

# Ověřit, že privátní klíč odpovídá certifikátu (výstupy md5 musí být shodné)
openssl x509 -noout -modulus -in cert.pem | openssl md5
openssl rsa  -noout -modulus -in key.pem  | openssl md5

testssl.sh — komplexní audit jedním příkazem

testssl.sh je bash skript, který otestuje vše najednou: verze protokolů, cipher suites, OCSP stapling, HSTS, certifikát a desítky známých zranitelností (BEAST, ROBOT, Heartbleed, POODLE, LUCKY13…).

git clone --depth 1 https://github.com/drwetter/testssl.sh.git
cd testssl.sh
./testssl.sh naseit.cz

Online nástroje

• SSL Labs (ssllabs.com/ssltest) — nejznámější, dá serveru hodnocení A–F, detailní rozbor cipher suites, protokolů a zranitelností
• crt.sh — vyhledávání v Certificate Transparency logu, přehled všech vydaných certifikátů pro doménu
• badssl.com — sbírka záměrně špatně nakonfigurovaných HTTPS serverů pro testování reakce prohlížeče a klientských knihoven

Shrnutí — checklist pro správce

TLS je páteř bezpečnosti moderního webu. Správná konfigurace není jednorázová akce — standardy se vyvíjejí a nové zranitelnosti se objevují. Praktický checklist pro produkční server:

• Protokoly: povoleny pouze TLS 1.2 a TLS 1.3, TLS 1.0 a 1.1 vypnuty
• Cipher suites: pouze AEAD (AES-GCM, ChaCha20-Poly1305), CBC cipher suites zakázány
• Forward secrecy: cipher suites s ECDHE nebo DHE, žádné RSA key transport
• Certifikát: platný, SAN pokrývá všechny varianty domény (s www i bez), automatická obnova otestována přes --dry-run
• OCSP Stapling: zapnuto na webserveru
• HSTS: hlavička Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
• CAA záznamy: DNS záznamy omezující, které CA smějí vydávat certifikáty pro vaši doménu
• CT monitoring: alert při vydání nového certifikátu pro vaši doménu
• Audit: výsledek SSL Labs alespoň A (ideálně A+)

Pokud chcete mít jistotu, že vaše servery a aplikace jsou nakonfigurované správně a bezpečně, nebo potřebujete pomoci s nasazením mTLS, implementací zero-trust přístupu nebo auditem TLS konfigurace v celé vaší síťové infrastruktuře — ozvěte se nám.