Web stále funguje, ale automatická obnova certifikátu končí chybou CAA. To je možné: CAA ovlivňuje oprávnění k vystavení certifikátu, nikoli běžné doručování už vydaného certifikátu návštěvníkovi. Záznam proto může působit nenápadně až do další obnovy. Před jeho změnou potřebujete zjistit, kdo certifikáty skutečně vystavuje pro hosting, CDN i další používané služby.
Co CAA určuje
CAA je typ DNS záznamu, kterým provozovatel vyjadřuje, které certifikační autority smějí vydávat certifikáty pro příslušné jméno. Není to adresa serveru ani soubor certifikátu. Pokud relevantní omezení neexistuje, CAA samo výběr autority nezužuje; to však neznamená, že kdokoli může bez ověření získat důvěryhodný certifikát.
CAA nenahrazuje ochranu účtu u registrátora, DNSSEC ani zabezpečení serveru. Je jednou konkrétní vrstvou politiky vystavování. Její přínos má smysl posuzovat společně se správou změn: přísná politika bez inventury služeb může při obnově zablokovat také legitimního poskytovatele. Správná hodnota vychází z vašeho provozu, ne z cizího vzoru.
Pro čtenáře, který zatím nerozlišuje A, MX a TXT, je vhodný základní průvodce DNS. Tento návod řeší užší otázku: jak CAA připravit, kontrolovat a diagnostikovat bez zbytečného přerušení vydávání certifikátů. Nejde o univerzální konfiguraci pro všechny hostingy.
Nejdříve inventura vydavatelů
Na veřejném webu můžete vidět certifikát CDN, zatímco původní hosting používá jinou autoritu. Další vlastní subdoména může sloužit newsletterové nebo zákaznické platformě. Seznam certifikátů jen z prohlížeče proto nemusí stačit k určení budoucích potřeb. Zeptejte se každého poskytovatele na podporovanou CAA politiku a případné další vydavatele, které používá.
- Hlavní web: kdo vystavuje certifikát a kdo odpovídá za obnovu?
- CDN nebo proxy: jaké autority potřebuje pro vlastní doménu zákazníka?
- Původní server: má samostatný certifikát a jak se obnovuje?
- Externí aplikace: vyžaduje vlastní jméno, alias nebo specifické ověření?
- Wildcard: používá se skutečně a potřebuje jinou politiku než běžná jména?
Vlastníkem odpovědi má být člověk, který spravuje danou službu. Redaktor nemusí mít přístup do certifikační automatizace a nemá potřebné údaje odhadovat. Do evidence stačí název služby, dotčené jméno, potvrzené požadavky a datum kontroly. Soukromé klíče a přístupové tokeny do ní nepatří.
issue a issuewild nejsou totéž
V běžné politice narazíte na vlastnost issue a případně issuewild pro wildcard certifikáty. Pokud zvláštní issuewild chybí, může se na wildcard vztahovat issue. Více povolujících záznamů stejného typu se podle standardu uplatňuje souběžně; nejde o pořadí záložních řádků, z nichž by se použil jen první.
Let’s Encrypt ve své dokumentaci uvádí identifikátor letsencrypt.org. To není důvod vložit jej automaticky na web, který využívá jiného vydavatele. Další parametry mohou omezovat i způsob ověření či účet, ale bez znalosti konkrétní automatizace mohou obnovu zbytečně znemožnit. Začínejte potvrzenou potřebou, nikoli maximem dostupných omezení.
| Položka k posouzení | Co znamená pro rozhodnutí | Co předem zjistit |
|---|---|---|
| issue | Omezení běžného vystavování | Potřebné autority používaných služeb |
| issuewild | Samostatná politika pro wildcard | Zda wildcard používáte a kdo jej vydává |
| Více povolených autorit | Více legitimních možností vydání | Zda všechny skutečně potřebujete |
| Doplňující parametry | Užší podmínky pro podporující autoritu | Soulad s účtem a způsobem automatizace |
Zkontrolujte jméno, nadřazenou politiku i alias
Při hledání relevantní politiky může hrát roli nadřazené jméno. Podle dokumentace Let’s Encrypt se zohledňuje nejbližší nalezená CAA sada a vyhledávání také následuje CNAME. Prostý pohled na prázdné pole konkrétní subdomény v panelu tedy nemusí znamenat, že ji žádná politika neovlivňuje.
U aliasu navíc nekombinujte libovolně CNAME a další záznamy na stejném jméně. Pokud subdoména míří na externí platformu, požadujte její konkrétní podporovaný postup. Neobcházejte zákaz panelu změnou záznamu, jehož význam neznáte. Případnou výjimku nebo jiný způsob připojení musí potvrdit správce DNS a poskytovatel služby.
Bezpečný postup změny
- Uložte aktuální relevantní DNS odpovědi a vymezte jména, kterých se změna týká.
- Sepište všechny používané vydavatele a jejich potvrzené požadavky.
- Připravte minimální politiku odpovídající těmto požadavkům a potřebným wildcardům.
- Změňte pouze schválené záznamy a ověřte odpovědi skutečných autoritativních serverů.
- Proveďte podporovanou kontrolu vystavení či obnovy a sledujte další automatický cyklus.
Nespoléhejte jen na okamžité otevření webu po změně. Již vydaný certifikát může fungovat dál a chybu odhalí až příští vystavování. Pokud poskytovatel nabízí testovací prostředí, využijte je podle jeho dokumentace. Testování ale nemá znamenat opakované neřízené ostré žádosti, které mohou narazit na provozní limity.
Při přejímce rozlišujte uloženou změnu v panelu, veřejnou DNS odpověď a ověřenou možnost obnovy. To jsou tři různé důkazy. Pokud jste prověřili jen první dva, napište to do záznamu a nepřidávejte tvrzení, že celý automatický proces už proběhl. Stejné pravidlo pomůže při předání správy novému dodavateli.
Jak číst chybu při obnově
Chyba CAA nemusí znamenat jen úmyslně zakázaného vydavatele. Dokumentace Let’s Encrypt popisuje také problémy DNS odpovědí a SERVFAIL, který může souviset s validací DNSSEC nebo dostupností jmenných serverů. Prázdná odpověď a chyba dotazu nejsou stejný stav. Diagnostika musí rozlišit, co se při kontrole opravdu vrátilo.
| Výsledek | Co nejprve prověřit | Potřebný podklad |
|---|---|---|
| Autorita není povolená | Relevantní CAA politika a požadovaný vydavatel | Konkrétní jméno a chyba žádosti |
| Běžný certifikát projde, wildcard ne | Samostatné wildcard omezení | Typ požadovaného certifikátu |
| DNS dotaz selhává | Autoritativní servery a DNSSEC | Skutečná odpověď a čas kontroly |
| Panel je prázdný, chyba trvá | Nadřazená politika a případný alias | Cesta hledání relevantní sady |
Model: CDN funguje, původní server čeká
Firma v modelu povolí jen autoritu viditelnou u veřejného webu. CDN dál funguje, ale hosting používá pro původní server jiného vydavatele. Při jeho obnově nastane chyba. Diagnóza „certifikát na webu je zelený“ problém přehlédne, protože sleduje jinou část spojení.
Řešením modelové situace je potvrdit skutečné potřeby obou služeb, upravit schválenou politiku a ověřit obnovu na správné vrstvě. Není nutné rušit všechna omezení ani naslepo přidávat dlouhý seznam autorit. Dobrý závěrečný záznam vysvětluje, která služba co potřebuje a kdo to ověřil. Při další změně hostingu tak tým ví, co musí znovu posoudit.
Časté otázky
Přestane web ihned fungovat po změně CAA?
CAA řídí vystavování certifikátů. Již vydaný certifikát se samotnou změnou tohoto záznamu automaticky neodstraní. Chyba se proto může projevit až při další obnově nebo při přidání nového jména.
Musím CAA zavést na každém webu?
Nejde o automatické redakční nastavení. Má smysl jako vědomě spravovaná politika s přehledem vydavatelů. Pokud neznáte požadavky hostingu a dalších služeb, začněte jejich inventurou a podporovaným postupem.
Stačí povolit vydavatele z prohlížeče?
Nemusí. Prohlížeč může vidět certifikát CDN, zatímco původní server a externí aplikace mají vlastní vystavování. Ověřte všechny služby v zamýšleném rozsahu politiky.
Znamená SERVFAIL zákaz vydavatele?
Ne nutně. Jde o selhání DNS dotazu, jehož příčinu je třeba dohledat. Může souviset například s validací DNSSEC nebo dostupností autoritativního serveru. Nezaměňujte je za běžnou prázdnou CAA odpověď.
Co přidat do předávací dokumentace?
Dotčená jména, potvrzené vydavatele, význam případných wildcard omezení, správce změny a datum skutečné kontroly. Přiložte výsledek ověření obnovy, pokud proběhla. Tajné klíče ani tokeny do tohoto přehledu nepatří.
