Vlastní doména uvízlá při validaci SSL
Vlastní doména, která zůstává ve stavu validace, obvykle selhává kvůli jednomu ze čtyř problémů: typu záznamu, proxy před challenge, propagaci, kterou nevidíte, nebo záznamu CAA. Ověřte je v tomto pořadí.
Přidali jste záznam. dig ho zobrazuje. Platforma stále hlásí čekání a tento stav trvá už hodinu. Vlastní doména uvízlá při validaci je frustrující právě proto, že všechny kontroly, které můžete sami provést, vypadají v pořádku.
Existují čtyři příčiny, všechny jsou mechanické a níže uvedené pořadí je odhalí nejrychleji.
Za prvé: co validace skutečně provádí
Než certifikační autorita vydá certifikát, musí ověřit, že daný název ovládáte. Existují dva běžné způsoby a to, který z nich vaše platforma používá, ovlivňuje, co se může pokazit:
- HTTP-01 — CA požádá o
http://your-domain/.well-known/acme-challenge/<token>a očekává konkrétní řetězec. To vyžaduje, aby běžné HTTP požadavky na vaši doménu dorazily na platformu. - DNS-01 — CA hledá TXT záznam. To vyžaduje, aby záznam existoval a byl viditelný pro resolver CA, což nemusí být resolver, který jste dotazovali.
Téměř za každou uvízlou validací stojí něco, co se nachází mezi CA a jednou z těchto dvou věcí.
Příčina 1: proxy před challenge
Tohle je nejčastější příčina, když je doména za CDN, a je skutečně matoucí, protože proxy je obvykle přesně to, co jste chtěli použít.
Pokud je váš DNS záznam proxovaný místo přímého směrování na platformu, HTTP-01 požadavek CA se ukončí na proxy. Proxy poskytne vlastní certifikát, použije vlastní pravidla a může vrátit redirect, challenge stránku nebo 404 — nic z toho však neobsahuje token, na který CA čeká.
Řešením je nechat challenge projít:
- Vypněte proxy (přepněte záznam na grey-cloud), dokud se certifikát nevydá, a potom ji znovu zapněte.
- Nebo z pravidel pro redirect či přístup vylučte
/.well-known/acme-challenge/*.
Záludnost spočívá v tom, že ochrany typu „Always Use HTTPS“ a „Under Attack“ rozbíjejí HTTP-01, přestože z pohledu vašeho prohlížeče web funguje dokonale.
Příčina 2: nesprávný typ záznamu
Většinu zbývajících problémů způsobují dvě chyby:
A záznam směřující na adresu, která se mění. Pokud vám platforma poskytla hostname, použijte CNAME. Zkopírování aktuální IP adresy do A záznamu funguje jen do chvíle, než se adresa změní.
CNAME na apexu zóny. example.com nemůže podle standardů obsahovat CNAME současně se svými záznamy SOA a NS. Někteří poskytovatelé nabízejí jako řešení ALIAS, ANAME nebo „CNAME flattening“, jiní ne. Pokud to váš poskytovatel nepodporuje, použijte subdoménu — app.example.com — a apex přesměrujte.
# What the world actually sees, not what your dashboard shows
dig +short app.example.com CNAME
dig +short app.example.com A
Pokud jsou oba výsledky prázdné, na ničem dalším z tohoto seznamu zatím nezáleží.
Příčina 3: propagace, kterou neměříte
dig bez argumentů se dotazuje vašeho resolveru, který mohl odpověď, kterou jste právě vytvořili, uložit do cache — nebo ještě hůř, mohl mít v cache NXDOMAIN z doby před vytvořením záznamu. Negativní záznam v cache s dlouhým TTL je skutečně častým důvodem, proč validace hodinu selhává a potom bez jakéhokoli zásahu uspěje.
Dotazujte se přímo autoritativních serverů a také veřejného resolveru, abyste zjistili, co pravděpodobně uvidí CA:
# Ask the zone's own nameservers
dig +short app.example.com @$(dig +short NS example.com | head -1)
# Ask a resolver outside your network
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8
Pokud je autoritativní odpověď správná a veřejné resolvery poskytují nesprávnou odpověď, čekáte na TTL a není co opravovat.
Příčina 4: CAA odmítá vydavatele
Tato příčina je vzácná, při běžných DNS kontrolách neviditelná a při výskytu zcela tichá.
Záznam CAA na vaší doméně určuje, které certifikační autority pro ni smějí vydávat certifikáty. Pokud takový záznam máte — často zděděný ze staršího nastavení nebo přidaný na základě doporučení bezpečnostního skenu — a neobsahuje CA, kterou používá vaše platforma, vydání selže. Jediné místo, kde se to projeví, jsou logy CA, ke kterým nemáte přístup.
dig +short example.com CAA
dig +short app.example.com CAA
Prázdný výstup znamená, že neplatí žádné omezení, což je v pořádku. Pokud se záznamy zobrazí, buď přidejte CA používanou vaší platformou, nebo omezení odstraňte.
Pořadí, které problém odhalí nejrychleji
- Pomocí
digověřte záznam přes veřejný resolver. Žádná odpověď znamená, že je záznam nesprávný nebo se ještě nepropagoval — zde skončete. - Ověřte, zda je záznam proxovaný. Pokud ano, proxy vypněte nebo vylučte ACME cestu.
- Zkontrolujte CAA na apexu i subdoméně.
- Teprve potom zvažte, že je problém na straně platformy.
Devadesát procent uvízlých validací skončí v kroku 1 nebo 2.
Jak to funguje na Dockup
Dvě konstrukční volby odstraňují většinu dohadů.
DNS záznam se vytvoří za vás. Pokud je vaše zóna na Cloudflare a připojili jste účet, přidání domény zapíše záznam samo, místo abyste hodnotu ručně kopírovali:
dockup domain add app.example.com my-project/my-api --port 3000 --cloudflare
Tím se odstraní celá skupina chyb způsobených překlepy a nesprávným typem záznamu — platforma ví, zda potřebuje CNAME, nebo A záznam, a vytvoří správný typ.
Oprávnění jsou dvě. Zone:Read a DNS:Edit, nic dalšího. Dockup nemůže číst vaše ostatní zóny, měnit nastavení účtu ani zasahovat do ničeho, k čemu nedostal oprávnění. Připojení DNS automatizace by nemělo vyžadovat předání celého účtu.
Stav ověření a certifikátu je viditelný pro každou doménu zvlášť, nikoli jako jeden souhrnný stav. „DNS ověřeno, ale TLS čeká“ tak znamená přesně to, co má — jde o dva samostatné kroky, z nichž jeden je dokončený.
Často kladené otázky
Jak dlouho by mělo vydání certifikátu trvat? Jakmile se DNS správně překládá, obvykle méně než minutu. Pokud stav čekání trvá déle než přibližně patnáct minut, něco vydání blokuje, nejde jen o pomalé zpracování.
Proč moje doména funguje v prohlížeči, ale validace selhává? Protože prohlížeč následuje redirecty a používá HTTPS, zatímco challenge nedělá ani jedno. Proxy, která váš web obsluhuje dokonale, může přesto pohltit běžný HTTP ACME požadavek.
Mohu na kořenové doméně použít CNAME? Ve standardním DNS ne. Použijte funkci poskytovatele, jako je ALIAS nebo CNAME flattening, případně nasměrujte apex na subdoménu pomocí redirectu.
Co je záznam CAA a potřebuji ho? Omezuje, které certifikační autority smějí pro vaši doménu vydávat certifikáty. Potřebovat ho nemusíte, ale pokud máte záznam CAA, ve kterém chybí CA vaší platformy, vydání certifikátu selže bez viditelné chybové zprávy.
