DNS a SSL: DNS záznamy, DNSSEC, TLS, certifikáty a kompletní checklist

Příklady:

• platný certifikát nepomůže, pokud záznam A míří na starý server,
• správný záznam A nestačí, pokud AAAA směruje provoz IPv6 na nefunkční stroj,
• automatická obnova certifikátu nezafunguje, pokud záznam _acme-challenge nelze vytvořit nebo je port 80 blokovaný,
• DNSSEC může zvýšit důvěru v odpovědi DNS, ale chybný záznam DS může způsobit SERVFAIL pro celou doménu,
• krátký TTL neopraví špatnou delegaci jmenných serverů,
• zástupný certifikát (wildcard) nezahrnuje hlavní doménu ani víceúrovňové subdomény, pokud nebyly zapsány samostatně.

V roce 2026 by měla být správa certifikátů plně automatická. Od 15. března 2026 mohou mít veřejné certifikáty TLS typu Subscriber Certificate maximálně 200 dní platnosti. Limit klesne na 100 dní v březnu 2027 a na 47 dní v březnu 2029. Let’s Encrypt stále ve výchozím nastavení vydává 90denní certifikáty, ale nabízí také kratší profily, a od května 2026 profil tlsserver vydává 45denní certifikáty pro uživatele, kteří jej vědomě zvolí.

TL;DR: udržujte alespoň dva nezávisle dostupné autoritativní servery DNS, kontrolujte záznamy A a AAAA, nasaďte DNSSEC pouze s bezpečným procesem správy DS, omezte certifikační autority pomocí CAA, používejte TLS 1.3 s TLS 1.2 jako kompatibilním minimem, automatizujte vydávání a obnovu certifikátů prostřednictvím ACME a sledujte datum platnosti, řetězec certifikátů, SNI, HSTS a chyby validace z více lokalit.

Informace a požadavky byly ověřeny 23. července 2026.

DNS, SSL a TLS v jedné tabulce

Vrstva	Odpovídá za	Nejdůležitější prvky	Typické výpadky
Registrátor domény	vlastnictví domény a delegaci	jmenné servery, blokace transferu, DS	převzetí účtu, špatná delegace, starý DS
Autoritativní DNS	skutečné záznamy zóny	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	špatná adresa, chybějící záznam, split-brain, špatný podpis
Rekurzivní resolver	nalezení a cache odpovědi	TTL, cache, validace DNSSEC, DoH/DoT	stará data v cache, chybná validace
TCP/QUIC a TLS	bezpečný kanál k serveru	TLS 1.2/1.3, SNI, ALPN, certifikát	slabý protokol, chybný chain, hostname mismatch
Certifikát	potvrzení identity názvu	SAN, issuer, platnost, klíč, podpis	vypršení, chybějící název, špatný intermediate
HTTP	přesměrování a politika HTTPS	301/308, HSTS, bezpečnostní hlavičky	redirect loop, mixed content, chybějící HSTS

Jak ve skutečnosti funguje překlad domény?

DNS je hierarchický a distribuovaný systém názvů. Resolver nedostává celou odpověď z jednoho centrálního serveru. Zjednodušeně:

1. prohlížeč a systém kontrolují lokální cache,
2. rekurzivní resolver se ptá root serverů,
3. root ukazuje na servery příslušné domény nejvyšší úrovně, například .pl,
4. server TLD ukazuje na autoritativní servery domény,
5. autoritativní server vrací záznam, například A, AAAA nebo CNAME,
6. odpověď se ukládá podle TTL.

użytkownik
   ↓
lokalny cache
   ↓
rekurencyjny resolver
   ↓
root → TLD → autorytatywny DNS
   ↓
A / AAAA / CNAME / HTTPS
   ↓
połączenie TLS z serwerem

DNS nezaručuje, že uvedený server je v pořádku, ani že odpověď HTTP bude správná. Vrací data uložená v zóně. Monitoring DNS by proto měl být propojen s testy TCP, TLS a HTTP.

1. Nejdůležitější záznamy DNS

A a AAAA

example.com.      300 IN A     192.0.2.10
example.com.      300 IN AAAA  2001:db8::10

• A ukazuje na adresu IPv4,
• AAAA ukazuje na adresu IPv6.

Záznam AAAA není doplněk bez následků. Pokud existuje, klienti podporující IPv6 se mohou pokusit připojit právě k němu. Nezveřejňujte AAAA, dokud firewall, routing, webový server, certifikát a challenge ACME nefungují správně přes IPv6.

Let’s Encrypt při validaci http-01 preferuje IPv6, pokud má doména záznam AAAA. Chybné IPv6 může způsobit neúspěšné vydání nebo obnovu certifikátu i tehdy, když je IPv4 správné.

CNAME

www.example.com.  300 IN CNAME app.hosting.example.

CNAME vytváří alias na jiný název DNS. Název s CNAME by neměl mít současně jiná běžná data, jako jsou A, AAAA nebo MX, protože CNAME označuje, že vlastní data se nacházejí pod jiným názvem.

Na apexu zóny, tedy example.com, klasický CNAME koliduje s povinnými záznamy SOA a NS. Poskytovatelé to obcházejí vlastními mechanismy ALIAS, ANAME nebo flattening, ale nejde o běžné záznamy CNAME přenášené v zóně.

NS a SOA

example.com.  86400 IN NS ns1.dns-provider.example.
example.com.  86400 IN NS ns2.dns-provider.example.

NS určuje autoritativní jmenné servery. Delegace u registrátora a záznamy NS uvnitř zóny by měly být konzistentní.

SOA obsahuje administrativní data zóny, mimo jiné sériové číslo a parametry používané sekundárními servery. Při ruční správě zóny musí sériové číslo po změnách narůstat.

Dobrá provozní praxe jsou alespoň dva autoritativní servery provozované v oddělených sítích nebo lokalitách. ICANN doporučuje více oddělených autoritativních serverů, nejlépe geograficky a topologicky rozdělených.

MX

example.com.  3600 IN MX 10 mail1.example.net.
example.com.  3600 IN MX 20 mail2.example.net.

Nižší číslo znamená vyšší prioritu. Cíl záznamu MX by měl být název hostitele, nikoli adresa IP ani CNAME.

Změna webhostingu by neměla automaticky měnit poštu. Před migrací DNS si poznamenejte záznamy MX, SPF, DKIM a DMARC.

TXT

TXT je textový kontejner používaný mimo jiné pro:

• SPF,
• DKIM,
• DMARC,
• validaci vlastnictví domény,
• ACME dns-01,
• integrace SaaS.

example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"

Více záznamů TXT pod jedním názvem může být správných, ale několik konkurujících si záznamů SPF začínajících na v=spf1 je chyba návrhu.

CAA

CAA umožňuje vlastníkovi domény určit, které certifikační autority mohou vydávat certifikáty pro doménu.

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

• issue se týká běžných certifikátů,
• issuewild se týká zástupných (wildcard),
• iodef označuje kanál pro hlášení porušení politiky.

CAA nenahrazuje kontrolu účtu u registrátora, DNSSEC ani monitoring Certificate Transparency. Je to dodatečné omezení pro veřejné CA. Chybějící CAA obvykle znamená, že každá veřejně důvěryhodná CA může vydat certifikát po správné validaci domény.

PTR

PTR realizuje reverzní DNS, tedy mapování adresy IP na název. Záznam nastavuje vlastník rozsahu IP, obvykle poskytovatel VPS nebo hostingu. Je obzvláště důležitý pro poštovní servery.

192.0.2.10 → mail.example.com

Pro poštu by měl název PTR obvykle vést zpět přes A nebo AAAA na stejnou adresu.

HTTPS a SVCB

Záznamy HTTPS a SVCB mohou klientovi předávat informace o způsobu připojení ke službě, alternativních endpointech, podporovaných protokolech a parametrech potřebných před navázáním připojení.

Koncepční příklad:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"

Neměli byste zapisovat ipv4hint nebo ipv6hint jako náhradu správných adresních záznamů bez pochopení chování klientů. HTTPS RR je mechanismus optimalizace a signalizace, nikoli oprava chybného DNS nebo TLS.

2. TTL a „propagace DNS"

TTL určuje, jak dlouho může resolver uchovávat odpověď v cache. Neexistují jediné globální hodiny propagace. Po změně:

• část resolverů má ještě starou odpověď,
• část se serveru dotáže okamžitě,
• negativní odpovědi, jako je NXDOMAIN, mohou být také ukládány do cache,
• lokální systém, prohlížeč, operátor a aplikace mohou mít samostatnou cache.

Rozumné hodnoty TTL

Situace	Typická hodnota
stabilní produkční záznam	3600-86400 s
příprava migrace	300-600 s
záznam ACME DNS-01	30-300 s, pokud to poskytovatel umožňuje
záznam NS nebo SOA	obvykle delší
nouzové přepnutí	nízký TTL pomůže až po vypršení dřívější cache

Před migrací snižte TTL alespoň o jeden starý interval TTL dříve. Snížení TTL pět minut před změnou neodstraní odpovědi, které si resolver už uložil na 24 hodin.

Po dokončení migrace TTL zvyšte, abyste omezili počet dotazů a závislost na chvilkových problémech autoritativního DNS.

3. DNSSEC: integrita odpovědi, nikoli šifrování

DNSSEC přidává ověření původu dat DNS a ochranu integrity pomocí digitálních podpisů. Nešifruje dotazy ani neskrývá názvy domén před poskytovatelem sítě nebo resolverem.

Řetězec důvěry využívá mimo jiné:

• DNSKEY - veřejné klíče zóny,
• RRSIG - podpisy sad záznamů,
• DS - otisk klíče uložený v nadřazené zóně,
• NSEC nebo NSEC3 - kryptografické potvrzení neexistence názvu nebo typu.

root
  ↓ podpisana delegacja
TLD
  ↓ rekord DS
example.com
  ↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA

RFC 9364 označuje použití DNSSEC k ověřování původu dat DNS za aktuální dobrou praxi.

Největší riziko DNSSEC

Nejčastějším problémem není chybějící DNSSEC, ale chybný řetězec DNSSEC. Pokud u registrátora zůstane záznam DS odkazující na starý klíč a nový operátor DNS podepisuje zónu jiným klíčem, validující resolvery vrátí SERVFAIL.

Bezpečná migrace DNSSEC vyžaduje:

1. ověření, kdo podepisuje zónu,
2. stanovení metody transferu nebo rolloveru klíčů,
3. zveřejnění správného DS v nadřazené doméně,
4. vyčkání na TTL záznamů DNSKEY a DS,
5. teprve poté odstranění starých klíčů nebo staré zóny,
6. testování prostřednictvím validujících resolverů.

Nezapínejte DNSSEC, pokud poskytovatel nezajišťuje jasný proces správy DS a rotace klíčů.

4. DNSSEC versus DoH a DoT

Tyto mechanismy řeší jiné problémy:

Mechanismus	Chrání	Neposkytuje
DNSSEC	autenticitu a integritu dat DNS	důvěrnost dotazu
DNS over TLS	šifrování mezi klientem a resolverem přes TLS, obvykle port 853	autenticitu dat bez validace DNSSEC
DNS over HTTPS	šifrování DNS v HTTPS	autenticitu dat bez DNSSEC
běžný DNS	základní překlad názvů	důvěrnost a kryptografickou integritu

DNS over TLS popisuje RFC 7858 a DNS over HTTPS RFC 8484. Šifrovaný transport chrání dotaz před jednoduchým odposlechem na úseku klient-resolver, ale operátor resolveru dotazy stále vidí a další překlad závisí na jeho politice.

5. SSL a TLS: správná terminologie

„Certifikát SSL" je stále běžný marketingový termín, ale moderní weby používají TLS. SSL 2.0 a SSL 3.0 jsou zastaralé a TLS 1.0 a 1.1 byly formálně vyřazeny organizací IETF.

V roce 2026:

• TLS 1.3 by měl být preferován,
• TLS 1.2 zůstává kompatibilním minimem pro starší, stále podporované klienty,
• TLS 1.0, TLS 1.1, SSLv2 a SSLv3 by měly být vypnuty,
• konfigurace TLS 1.2 by měla používat moderní sady s AEAD a forward secrecy,
• server by neměl nabízet zastaralé algoritmy a výměny klíčů.

RFC 9325 obsahuje aktuální doporučení pro bezpečné používání TLS a nahradilo dřívější BCP 195.

6. Co prohlížeč v certifikátu kontroluje?

Během připojení TLS klient kontroluje mimo jiné:

1. zda je certifikát v období platnosti,
2. zda se název hostitele nachází v subjectAltName,
3. zda podpis vede přes správný mezilehlý řetězec k důvěryhodné root CA,
4. zda certifikát není použit k nesprávnému účelu,
5. zda jsou parametry připojení přijatelné,
6. zda politiky prohlížeče certifikát neodmítají.

Identita serveru se dnes ověřuje na základě SAN, nikoli pole Common Name jako primárního zdroje názvu.

SAN

Jeden certifikát může zahrnovat více názvů:

example.com
www.example.com
api.example.com

Každý název se musí nacházet v SAN.

Wildcard

*.example.com

zahrnuje:

www.example.com
api.example.com
shop.example.com

ale nezahrnuje automaticky:

example.com
www.eu.example.com

Hlavní doménu je nutné přidat samostatně a wildcard funguje pouze pro jednu úroveň štítku.

SNI

Server Name Indication umožňuje klientovi předat název hostitele během handshake, díky čemuž může jedna adresa IP obsluhovat více certifikátů. Chybná konfigurace SNI často způsobí zobrazení certifikátu jiné domény.

Řetězec certifikátů

Server by měl posílat certifikát domény a potřebné mezilehlé certifikáty, ale obvykle ne root. Chybějící intermediate může fungovat na jednom zařízení, které si certifikát dříve uložilo, a selhávat na jiném.

7. Platnost certifikátů v roce 2026

CA/Browser Forum přijalo harmonogram zkracování veřejných certifikátů TLS:

Datum vydání	Maximální platnost
před 15. březnem 2026	398 dní
15. března 2026 - 14. března 2027	200 dní
15. března 2027 - 14. března 2029	100 dní
od 15. března 2029	47 dní

To neznamená, že každá CA vydává certifikát na maximální období. Let’s Encrypt ve výchozím nastavení stále vydává 90denní certifikáty, má volitelné šestidenní certifikáty a profil tlsserver s 45denními certifikáty dostupný pro rané nasazení od května 2026.

Závěr je jednoduchý: ruční obnova certifikátů přestává být rozumnou provozní praxí.

8. ACME a automatizace certifikátů

ACME je standardní protokol automatizující registraci účtu, validaci kontroly domény, vydání, obnovu a zneplatnění certifikátu.

HTTP-01

CA stahuje soubor:

http://example.com/.well-known/acme-challenge/TOKEN

Výhody:

• jednoduchá konfigurace pro jednotlivý webový server,
• snadná automatizace,
• nevyžaduje API DNS.

Omezení:

• vyžaduje dostupný port 80,
• nevydává wildcard,
• challenge musí dorazit na správný server,
• chybné AAAA, proxy, redirect nebo load balancer mohou validaci přerušit.

Let’s Encrypt doporučuje ponechat port 80 pro veřejné webové servery a přesměrovávat běžný provoz na HTTPS.

DNS-01

Klient zveřejňuje TXT:

_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"

Výhody:

• podporuje wildcard,
• funguje bez veřejného HTTP serveru,
• hodí se pro centrální správu certifikátů.

Rizika:

• vyžaduje bezpečný přístup k API DNS,
• propagace a cache mohou validaci zpozdit,
• API token s právem úpravy celé zóny zvyšuje dopady úniku,
• staré TXT mohou ztížit diagnostiku.

Let’s Encrypt výslovně doporučuje používat DNS-01 s poskytovatelem nabízejícím API, protože automatizace obnov je klíčová. Přidělujte tokenu nejmenší možný rozsah: nejlépe pouze pro záznamy _acme-challenge, nikoli pro správu domény, účtu nebo všech zón.

Wildcard v Let’s Encrypt vyžaduje DNS-01.

TLS-ALPN-01

Validace probíhá prostřednictvím speciálního připojení TLS na portu 443 a protokolu ALPN. Je užitečná pro specializované proxy a systémy správy certifikátů, ale ručně se konfiguruje méně často.

Renewal Information

Moderní klient ACME by měl podporovat ACME Renewal Information, tedy ARI. Místo obnovy každého certifikátu podle jediné pevné hranice může klient obdržet od CA doporučené okno obnovy. Let’s Encrypt doporučuje kontrolovat informace ARI alespoň dvakrát denně.

9. CAA a ACME: praktický příklad

Pro certifikáty Let’s Encrypt:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Pokud nechcete wildcard:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"

Před vydáním má veřejná CA povinnost zkontrolovat CAA. Od 15. března 2026 požadavky CA/Browser Forum nařizují také validaci DNSSEC pro dotazy související s CAA prováděné z hlavní síťové perspektivy a chybu validace DNSSEC není dovoleno považovat za souhlas s vydáním.

Po změně CA nezapomeňte aktualizovat CAA před spuštěním nového procesu vydávání.

10. HTTPS, přesměrování a HSTS

Minimální schéma:

http://example.com
        ↓ 301 lub 308
https://example.com

Po potvrzení plné funkčnosti HTTPS lze přidat:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS informuje prohlížeč, aby v budoucnu používal pouze HTTPS a neumožnil obejít část chyb certifikátu.

Nezačínejte dlouhým max-age, includeSubDomains a preload, pokud:

• existují subdomény bez HTTPS,
• část infrastruktury spravuje partner,
• nebyl otestován proces obnov,
• chybí monitoring certifikátů,
• není jisté, zda bude stará služba i nadále potřeba.

HSTS preload umísťuje pravidlo do distribuce prohlížečů. Odstranění záznamu může trvat týdny.

11. Nejčastější chyby DNS

Chybný záznam AAAA

IPv4 funguje, ale část klientů volí nefunkční IPv6. Příznaky jsou náhodné podle sítě uživatele.

CNAME a jiné záznamy pod stejným názvem

Alias koliduje s adresními záznamy, MX nebo TXT. Panel poskytovatele může změnu blokovat nebo generovat nejednoznačnou zónu.

Nekonzistentní delegace NS

Registrátor ukazuje na jiné servery než zóna, nebo má jeden ze serverů starší verzi dat.

Starý DS po změně DNS

Doména vrací SERVFAIL pouze u resolverů validujících DNSSEC.

Trvale příliš nízký TTL

Zvyšuje počet dotazů a citlivost na chvilkovou nedostupnost DNS, nezajišťuje automaticky rychlý failover.

Příliš vysoký TTL před migrací

Staré adresy zůstávají v cache mnoho hodin.

Ponechané záznamy TXT

Staré ověřovací a ACME tokeny ztěžují audit a zvyšují provozní chaos.

Chybějící konzistence www a apex

example.com a www.example.com směrují do různých systémů, mají odlišné certifikáty nebo vytvářejí smyčku přesměrování.

12. Nejčastější chyby TLS a certifikátů

Certifikát vypršel

Nejčastěji není příčinou chybějící automatizace, ale automat, který přestal fungovat bez upozornění.

Certifikát nezahrnuje hostitele

Certifikát pro example.com automaticky nezabezpečuje www.example.com.

Neúplný chain

Chybí mezilehlý certifikát. Problém se může projevovat pouze na nových zařízeních nebo u vybraných klientů.

Špatný certifikát kvůli SNI

Reverzní proxy má chybný výchozí virtuální host, nebo nová doména nebyla přidána do mapování.

Staré protokoly a cipher suites

Server stále nabízí TLS 1.0/1.1 nebo staré sady, protože konfigurace pochází z doby před mnoha lety.

Chybějící shoda na více vrstvách

CDN má správný veřejný certifikát, ale připojení CDN→origin je nešifrované nebo neověřuje název hostitele.

Obnova provedena, ale proces server nenačetl znovu

Nový soubor certifikátu existuje na disku, ale Nginx, Apache, HAProxy nebo aplikace stále používá starý certifikát z paměti.

13. Diagnostika krok za krokem

Záznamy DNS

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Delegace

dig example.com NS
dig +trace example.com

DNSSEC

dig example.com A +dnssec
delv example.com A

SERVFAIL při fungování bez validace je silným signálem problému DNSSEC.

Certifikát a SNI

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Data certifikátu

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

TLS

openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2

HTTP a HSTS

curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/

Zkontrolujte redirect, Strict-Transport-Security, hostname, konečný status a absenci smyčky.

Můžete také použít bezplatný Inspektor DNS a SSL POLPROG, který zobrazuje záznamy DNS a informace o certifikátu TLS. Test doplňte pomocí Inspektoru bezpečnostních hlaviček, Kondice webu a článku Základy bezpečnosti webových aplikací.

14. Produkční monitoring

Nemonitorujte pouze domovskou stránku z jedné lokality. Minimální sada:

• odpověď autoritativního DNS,
• záznamy A, AAAA, CNAME, NS, MX a CAA,
• validace DNSSEC,
• dostupnost přes IPv4 a IPv6,
• data certifikátu,
• shoda SAN,
• úplný chain,
• TLS 1.2 a TLS 1.3,
• konečný redirect HTTP→HTTPS,
• HSTS,
• odpověď originu za CDN,
• fungování ACME a poslední úspěšná obnova.

Prahy upozornění certifikátu

Pro plně automatický systém:

Zbývající čas	Reakce
30 dní	varování nebo kontrola trendu
14 dní	alert vyžadující analýzu
7 dní	provozní incident
3 dny	kritický alert a eskalace
méně než 24 h	hrozící výpadek

Prahy je nutné přizpůsobit délce certifikátu. Pro šestidenní nebo 45denní certifikáty musí monitoring reagovat výrazně dříve, úměrně cyklu obnovy.

15. Bezpečnostní kontrolní seznam DNS a TLS

Registrátor a DNS

• Účet registrátora má MFA.
• Transfer domény je zablokován.
• Kontaktní údaje a proces obnovy jsou aktuální.
• Jsou používány alespoň dva autoritativní servery DNS.
• Servery běží v oddělených sítích nebo lokalitách.
• Delegace NS u registrátora a v zóně je konzistentní.
• Záznamy A a AAAA ukazují na aktivní infrastrukturu.
• IPv6 je skutečně monitorováno.
• Záznamy MX, SPF, DKIM a DMARC jsou při migracích zachovány.
• CAA povoluje pouze používané CA.
• Nejsou přítomny zbytečné záznamy TXT a ověřovací tokeny.
• TTL byl s předstihem snížen před migrací.
• TTL byl po stabilizaci zvýšen.
• Přístup k API DNS má minimální oprávnění.

DNSSEC

• Poskytovatel podporuje DNSSEC a rotaci klíčů.
• Záznam DS u registrátora odpovídá aktivnímu DNSKEY.
• Změny operátora DNS mají plán migrace DNSSEC.
• Staré DS a klíče jsou odstraněny až po vypršení cache.
• Doména je testována validujícím resolverem.
• Alert detekuje SERVFAIL a vypršení podpisů.

Certifikáty

• Certifikáty jsou vydávány a obnovovány prostřednictvím ACME.
• Obnova byla otestována, nejen první vydání.
• Proces po instalaci nového certifikátu server znovu načte.
• Všichni hostitelé se nacházejí v SAN.
• Wildcard je používán vědomě.
• Chain obsahuje správné intermediates.
• Soukromý klíč neopouští příslušný systém.
• Oprávnění ke klíči jsou omezená.
• Alerty fungují nezávisle na samotném klientu ACME.
• DNS-01 používá omezený API token.
• HTTP-01 funguje přes IPv4 a IPv6.
• Staging CA se používá pro testy automatizace.

TLS a HTTPS

• TLS 1.3 je zapnutý.
• TLS 1.2 zůstává pouze pro potřebnou kompatibilitu.
• TLS 1.0, TLS 1.1 a SSL jsou vypnuty.
• Server nenabízí zastaralé cipher suites.
• SNI vrací správný certifikát pro každého hostitele.
• HTTP přesměrovává přímo na HTTPS.
• Není přítomen mixed content.
• HSTS byl nasazen po etapách.
• includeSubDomains je bezpečné pro celou doménu.
• Preload byl před nahlášením analyzován.
• CDN→origin rovněž používá správně ověřované TLS.

Verdikt

Dobrá konfigurace DNS a TLS v roce 2026 stojí na čtyřech zásadách:

1. DNS musí být konzistentní a provozně odolný.
2. DNSSEC by měl být nasazen pouze se správnou správou DS a klíčů.
3. Certifikáty musí být spravovány automaticky prostřednictvím ACME.
4. TLS 1.3, správný chain, monitoring a HSTS jsou součástí jednoho procesu, nikoli samostatnými úkoly.

Největším rizikem není chybějící „zelený zámeček" v den spuštění. Je jím tichý výpadek o několik měsíců později: vypršelý certifikát, neaktuální záznam AAAA, ponechaný DS, token DNS s nadměrnými oprávněními nebo automat obnovy, který nikdo nesledoval.