Mozno si to predstavujem ako hurvinek valku.
Ale kazda domena je viazana na nejaky email, pre pripad poslania auth code pre zmenu vlastnika, presunu domeny do ineho DNS parking atd.
Tak je problem mat ucet na lets encrypt kde si mozem pridat domenu, a oni mi poslu na email vlastnika domeny autorizacny kod a pridam do lets encrypt uctu. A vnom sa vygeneruju dva kluce. Jeden do DNS a druhy pre validaciu zo strany napriklad NPM? Pripadne seriu klucov ..
Uvidime ako to bude presne fungovat.
Napriklad vas-hosting.cz nema API , takze ak tam mate DNS hosting, tak wildcard nepojdu spravit.
Napriklad wedos.cz ma API, tak idu spravit wildcard.
A bolo by fajn keby bola metoda ako spravit wildcard bez API. Napriklad tym manualnym zapisom.
Som zvedavy ako to vymysleli. Ale to sa asi dozveme az v roku 2026.
Ověřování pro wildcard záznamy nijak nesouvisí s tím, jestli poskytovatel DNS poskytuje nějaké API. Let's Encrypt nepoužívá žádné speciální API, prostě jen posílá DNS protokolem úplně normální DNS dotazy a zpracovává odpovědi.
Autentizace domény je založená na tom, že vy do DNS uvedete DNS záznam se speciálním DNS názvem (podle kterého ho Let's Encrypt najde) a hodnotou, kterou vám určí Let's Encrypt. Let's Encrypt si pak standardním DNS dotazem nechá přeložit ten speciální záznam a zkontroluje, zda je v něm ta hodnota, kterou vám poskytl. Pokud ano, ví, že jste vlastníkem té domény – protože útočník nemůže vědět, jakou hodnotu vám LE poskytl.
Dneska LE posílá novou hodnotu pro každý požadavek na ověření domény. Změna bude spočívat jen v tom, že pro nový způsob ověření se ta hodnota nebude měnit s každým požadavkem na ověření domény, ale bude pořád stejná pro dané doménové jméno. Takže vy ten záznam vložíte to DNS jednou, klidně ručně, protože to budete dělat jenom jednou.
Žádné API poskytovatele DNS služeb není potřeba, ani u starého způsobu. Jen u nového způsobu se ten klíč vloží do DNS jednou „na věky“, u současného způsobu DNS-01 se musel při každém ověření domény (tedy častěji než jednou za tři měsíce) vkládat jiný klíč. Což je celkem otrava to dělat ručně, takže reálně se to dělá automaticky přes API. Mimochodem, ACME vzniklo právě kvůli automatizaci vydávání certifikátů, takže pokud pak někdo musí ručně přidávat záznamy do DNS, je to z bláta do louže. Proto se metoda DNS-01 používá v drtivé většině případů tam, kde i správu DNS lze zautomatizovat.
ACME protokol (v části ověřování vlastnictví domény) funguje tak, že ACME klient pošle požadavek „chci ověřit (prokázat vlastnictví) domény xy“. ACME server odpoví „OK, podporuju metodu A, pro ni použij token abc a pak zavolej URL 123. Také podporuju metodu B, pro ni použij token def a nazvy ho bflmpsvz a pak zavolej URL 456. A do třetice podporuju metodu C, pro ni použij token ghi a pak zavolej URL 789.“ Ten, kdo provádí ověření, si jednu z těch metod vybere, připraví její ověření (uloží soubor na web server, nakonfiguruje TLS, vytvoří DNS záznam – a použije pro to hodnoty, které se dozvěděl v odpovědi. Struktura poskytnutých dat se může pro každou metodu ověření lišit). Když má data pro ověření připravená (a ideálně si sám zkontroloval, že tam jsou – třeba že už je vypropagovaný DNS záznam), zavolá znovu ACME klient certifikační autoritu na tom URL, které dostal spolu s údaji pro ověření. Tím řekne CA, kterou validační metodu si vybral a co má CA použít pro validaci vlastnictví domény.
Pak klient čeká a opakovaně se ptá CA, jestli už validace proběhla. Pokud ano, má na svém účtu nějakou dobu (je uvedená v článku, bude se zkracovat) validovanou danou doménu a může žádat o vystavení certifikátu, ve kterém je to jméno uvedeno.
Pak už může ACME klient žádat o certifikát. Uvede všechny domény, které v něm chce mít, CA ověří, že ke všem doménám má platnou validaci, a pokud ano, vystaví mu certifikát s požadovanými doménami. (Zase je to asynchronní, takže ACME klient pošle požadavek na vystavení certifikátu, dostane adresu, na kterou se pak má ptát, a jednou za čas se pak dotazuje, zda už je certifikát vystaven.)