Názory k článku Centralizovaná automatizace certifikátů pomocí nástroje uacme

Ten skriptík by mohl být výrazně kratší, kdyby se místo těch echo -n $radek | awk ... použil read do vice proměnných: read certName url key domeny. Příkaz read to rozpadne po jednotlivých slovech (resp. podle $IFS) a do poslední proměnné dá vše co zbyde.

Jinak celkem pěkný článek na aktuální téma.

Diky za clanek, tesim se na pokracovani.

Do diskuse bych nadhodil tema: jak resite vydani jednoho certifikatu a jeho distribuci mezi vic serveru? Typicky v situaci, kdy mate sluzbu dostupnou na vice serverech, a chcete pro ni jeden spolecny certifikat.

Nutnost overeni pomoci DNS-01 neresim, to je tak nejak automaticke, spis kde certifikat vydavate (a jak zabezpecujete pristupova data k API pro zmenu DNS - urcite nebudou na vsech serverech?), kam ho ukladate, jak vydanou/obcer­stvenou verzi distribuujete?

Já distribuci certifikátů na servery popisuji v dalším dílu, pomocí Ansible. Je vlastně jedno jestli chcete více certifikátů na jeden server nebo jeden certifikát na více serverů.

Resim to same. Zatim jsem reseni nevymyslel.

Varianty:
1] centralni bod - ansible, puppet, etc, ktery rekonfiguruje koncove servery/sluzby, propojeni na nejakou sluzbu typu step-ca apod. Vyzaduje fakt spolehlive napsane zdrojaky, protoze to bude rekonfigurovat bez manualniho spousteni (klidne kazdy den)
2] decentralizovane - na kazdem serveru sluzba, ktera obsluhuje certifikaty napr vuci step-ca. Nutno vyresit kolizi s 1]
3] totalni decentralizace - kazdy bod si resi certifikaty sam - kolize s limity na api

Co se tyce dns, tam bud sub dns dedikovany pro acme, nebo nova varianta pro dns overovani (nemenne klice), ktera je ve vyvoji.

Nejlepsi by bylo certifikaty zrusit.

> Nejlepsi by bylo certifikaty zrusit.

To je výborná poznámka. Dovolte mi dotaz: vymyslel jste nějakou za ně vhodnou náhradu?

(Kromě DANE, ke kterému to celé směřuje, ale tam je zase problém, že musí být dostatečně rozšířený DNSSEC.)

Nevsim sem si, ze bych kvuli ssh musel pouzivat nejaky prdly certifikaty.

A dane nema s dnsec spolecnyho zhola nic.

To skutečně nemusíte, ale pořád je tu problém bezpečného předání veřejného klíče, který je nutný pro ochranu před útokem z pozice prostředníka (MitM). Takže pro bezpečné použití SSH musíte mít jinou cestou bezpečně zjištěné veřejné klíče serveru. Což třeba já striktně dělám, ale podle mých zkušeností to velká část adminů ignoruje a prostě přijme jakýkoliv klíč. Není to naprosto myslitelné u běžných uživatelů při přístupu třeba k bankovnictví.

S DANE nemáte pravdu, ten je naopak postaven na DNSSEC a striktně vyžaduje jeho validaci. Protože informace o veřejném klíči má opět smysl jen v případě, že ji dostanete z ověřeného zdroje. Viz RFC 6698: „The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered.“

Kéž by to už k DANE dosměřovalo. Certifikáty jsou fakt otravné.

Z dane nevysmirujes kdo kam leze, u certifikatu si BFU nevypne "overovani" (cert transparency), takze pekne vis, kam kdy kdo lez.

Navic to taky provozne nic nestoji, takze tezko muzes provozovat nejakou ziskovku za ucelem provozu DANE.

Hele soudruzi ... jako post rozhodne pisu dyl nez 30 sekund, takze byste se treba mohli naucit pocitat do triceti, kdyz v roce 2026 neumite session.

Neni (dlouhodobe) vule u tvurcu majoritnich browseru. Ale chytlo se to aspon u mailovych sluzeb.

způsob popisovaný v článku mi připadá jako takový neřízení chaos, kdy se o vše stará sám server. Nechtěl bych to hlídat a spravovat nebo řešit problémy.

U několika klientů (a i pro sebe) jsem implementoval centralizované vydávání a distribuci certifikátů. Jako uložiště používám hashicorp vault (ale lze používat jakákoliv obdobná databáze). Pak mám jeden nebo více serverů, které komunikují s internetem a zajišťují získávání nových certifikátů (či vydávání pokud se jedná o interní), ty se pak ukládají do vault, odkud si je může být sama aplikace získávat nebo deployment z toho dělá připravené balíčky dat pro servery.

Výhoda je, že mi stejný systém funguje pro veřejné weby s veřejnými certifikáty a i pro ty interní s vlastním CA. Je mi jedno, kdo a jaký proces se stará o vydávání certifikátů.

Pokud je aplikace chytrá nebo v kubernetu, tak může dostat rovnou notifikaci o změně a sama si cert aktualizovat, když chytrá není, tak na každém serveru mám systemd službu, která dostává seznam domén pro které má certifikáty stahovat. Pro každou doménu pak mám samostatnou službu, na které může být jakákoliv jiná služba závislá a restartovat se při změně certifikátu (to funguje na takové ty legacy věci docela obstojně). Při deploymentu serveru mu rovnou do image strkám poslední certifikát, aby i úvodní bootstrap byl už v pořádku.

Jinak receno, vyrobil si dokonaly cil pro utok a zrusil veskerou byt i tak jen teoretickou funcionalitu certifikatu.

Ad „způsob popisovaný v článku mi připadá jako takový neřízení chaos, kdy se o vše stará sám server. Nechtěl bych to hlídat a spravovat nebo řešit problémy.“

Centralizované řešení zase představuje SPoF (single point of failure). A to jednak ve smyslu, že výpadek centra ohrožuje dostupnost všech služeb. A jednak ve smyslu, že přes něj lze napadnout všechny ostatní.

Na jednu stranu chápu tu snahu vše spravovat a mít vše pod kontrolou (byť je to někdy jen iluze). Ale mnohdy je vhodnější decentralizace a síť složená z kooperujících autonomních prvků.

Také je celkem dobrá praxe, že soukromý klíč vznikne na daném zařízení a nikdy ho neopustí. Pokud by náhodou došlo ke ztrátě, není to žádná tragédie a jen se nechá vygenerovat a certifikovat klíč nový. Je z toho pak i zřejmé, že jde o novou instanci se staronovou identitou (klíč i certifikát jsou nové, ale jméno stejné). Něco jiného je, když archivujeme data zašifrovaná pro daný certifikát (např. e-maily), tam by bylo škoda mít hromadu zašifrovaných dat a přijít o klíč k jejich odšifrování.

SPOF je defacto kazda CA sluzba...
Pokud ta centralni sluzba slouzi jen k sprave certifikatu (napr. step-ca), tak by mne docela zajimalo, jak z centralni sluzby jde napadnout vse ostatni. Ty certifikaty se prece z te sluzby spis stahuji, nez aby to sluzba nekam nahravala - vetsinou ani nebude vedet, kde vsude to je. A soukrome klice zustavaji taktez na te sluzbe.
A kdyby byly obavy z napadnuti vseho mozneho, tak to uz z principu je mozne z kazdeho IAAC kontroleru.

18. 12. 2025, 09:42 editováno autorem komentáře

soukromý klíč neopustí zařízení? A jak si tohle představuješ implementovat pro různé load balancery, terminátory provozu a další? Jak zajistíš, aby ti všechna různá zařízení generovala dostatečně náhodné klíče? A proč musíš distriubovat soukromý klíč s certifikátem? O tom jsem vůbec nemluvil a ten klíč může zůstat na zařízení a být tam.

Tohle ale celé může být velmi dobře decentralizované, prakticky to tak i máme, těch služeb je více, těch serverů, které to generují je také více. Vygenerované certifikáty jsou fyzicky na daném serveru/zařízení a je potřeba komunikovat pouze při jejich obnově nebo instalaci serveru.

U aplikací tam to je trochu jiné, ale mám zpravidla nikdy aplikace nemá veřejné certifikáty (ty mají nějaké terminátory na hraně sítě), ale používají svoje interní s malou platností a pro každé spuštění si generují nový. Bez vaultu mi stejně spadne celý kubernetes, že jo.

Mám rád, když spuštění služeb a serverů není závislé na třetí službě, proto se snažím, aby všechna data měly už servery bezpečně u sebe a komunikace byla potřeba jen při jejich aktualizaci/obnově.

Problém je, že vůbec celé řešení a způsob PKI je centralizovaný, musíme se starat o CA a mezilehlé, ty aktualizovat, musím řešit revoke, monitorovat signatury použitých certifikátů a vše aktualizovat okamžitě, bez toho služby neběží.

Za mě je velmi nebezpečné, když může libovolné množství serveru si nechávat vydávat veřejné ceritifikáty, míst, které pak musím hlídat je obrovské množství a stejně to je centralizované, protože využívám jednu službu, která mi je vydává, jsem obětí rate limitů, která ta služba má a řešit to v situaci, kdy si do toho buší každý server sám je obrovské riziko, že si takhle uříznu strom pod nohama, nemluvě o tom, že i poté pro interní provoz potřebuji mít dostupný internet na vydávání certifikátu. Veřejné certifikáty prakticky mají být jen při vstupu do infrastruktury a interně ideálně používat vlastní, které mám plně pod kontrolou. Pak mohu mít implementované cross sign a mít více samostatných uzlů, které umí vygenerovat certifikát či mít lokální oddělené od internetu.

19. 12. 2025, 10:17 editováno autorem komentáře

Já zrovna řeším v myšlenkovém experimentu, jak vydávat a obnovovat certifikáty na DNS resolverech v clusteru za load balancerem, které navíc potřebují certifikát pro IP adresu, takže ověření pomocí DNS nebude možné použít.

Dospěl jsem k závěru, že nejrobustnější bude, když si každý server v clusteru bude udržovat jen svůj vlastní certifikát. Zbývá ale vyřešit, jak provádě důkaz držení adresy pomocí http-01, když ověřovací dotaz autority může být load balancerem poslán na libovolný server.

Nejlepší řešení asi spočívá ve sdílení klíče účtu pro ACME a použítí bezestavového ověření pomocí http-01, které využívá faktu, že soubor, kterým se držení webserveru ověřuje, obsahuje jen statický hash veřejného klíče pro ACME a následně náhodnou nonci, která je ale shodná se jménem souboru. Pro jeden konkrétní klíč pro ACME se tedy dá v konfiguraci webserveru vyrobit bianco šek, potvrzující pozitivně jakékoli výzvy o které takový klíč požádal. Tím pádem bude jedno, když výzvu pro ověření sdílené adresy dostane úplně jiný server než ten, který o vystavení žádal. Jediné omezení je, že klíč pro ACME musí být sdílený.

Bezpečněji by se to dalo udělat tak, že se ověřovací soubor rozkopíruje na všechny servery za LB. Nebo bude vyhrazen jen jeden server na ověřování, na něj bude LB směrovat ověřovací provoz a ověřovací soubory se sejdou tam.

Problém clusteru je, že je celý navržen tak, aby mohl bezvýpadkově fungovat i v případě, že některý z nodů vypadne. A pokud se bavíme o 6denních certifikátech, je třeba počítat s tím, že některý z nodů bude mít výpadek tak dlouhý, že jeho certifikát mezitím exspiruje.

Mít tedy jeden centrální server na ověřování je problematické protože takový server může kdykoli vypadnout. Kopírování ověřovacích souborů je rozumná možnost, pokud by bezestavový režim nebyl možný, ale taky představuje problém v souvislosti s tím, že ne všechny nody mohou být vždycky dostupné, takže kopírování musí ignorovat případné chyby.

Nakonec ještě pokud se node probudí po dlouhé době a jeho certifikát exspiruje, je třeba ho nezařazovat do clusteru, dokud si certifikát neobnoví. Kontrola platnosti certifikátu tedy musí být součástí kontroly živosti ze strany load balanceru.

Lepší, než kopírovat ověřovací soubory na jednotlivé nody, by mi připadalo mít službu vyhrazenou pro ty ověřovací soubory. Ty kopírovat na nějaké sdílené úložiště (S3) a veškerý provoz směrovaný na /.well-known/acme-challenge/ směrovat na službu nad tímto sdíleným úložištěm.

Jistěže ten tvůj způsob funguje, jen jsem přemýšlel o tom, jak to udělat „správně“ – bez toho, aby server slepě odpovídal i na falešné výzvy. protože to je určité bezpečnostní riziko – resp. zavádí to do systému nové předpoklady, jejichž splnění ty si zajistíš, ale někde jinde by splněné být nemusely.

Poznámka: Dnes už CA konečně dbají na správnost CAA záznamů v DNS. Dlouhou dobu jim to bylo jedno. Ale dnes bez správného CAA záznamu vám CA doménu nezaregistruje.

To dnes je ve skutečnosti 8. září 2017, kdy nabyl účinnosti Ballot 187 CA/B fóra. Tedy už to tak je nějaký pátek.

Fakt? ...chmm Sectigo Limited ... staci mit na domene libovolnej mail a voiala, mam cert. CAA je jim uplne burt.

Tak to mám bohužel jinou zkušennost. Certifikáty dostáváme přes Cesnet (a ten je součástí Geantu, který soutěží dodavatele) a tím pádem se nám CA často mění (zhruba každé dva roky). Teď máme necelý rok Haricu, předtím jsme měli Digicert. A když se v roce 2022 Digicert zaváděl, správné CAA ještě nevyžadoval. Zkoušel jsem to :-)

Nemít správné CAA záznamy by nemělo být nutné ani dnes. Důležité je nemít takové CAA záznamy, které vydání znemožňují.

Nevím přesně, jak fungují certifikáty od Geántu, ale není možné, že se požadovaný řetězec v CAA nemusí při změně měnit?

Nějak se mi nechce věřit, že by nějaká velká a známá autorita takhle okatě ignorovala požadavky CA/B fóra a nikdo by si toho za tolik let nevšiml.

Geant je takový garant, Cesnet technický řešitel. Certifikáty žádáme a dostáváme přímo od Cesnetu a ten má s CA nějaké API.

CAA se při změně CA musí měnit, při přechodu na Haricu se mi jinak nedařilo registrovat domény. A že to Digicert netestoval, říkám jen na základě vlastních zkušenností z té doby. Dnes to už mají třeba správně.

Velká známá autorita? Ta banda co nám loni najednou z ničeho nic vypověděla běžící smlouvu pár měsíců před jejím oficiálním doběhnutím. Myslím tím celému Geantu. Bez zdůvodnění. Mohou si to dovolit asi proto, že jsou tak velcí a známí. Dnes k nim mám averzi.

Ověření CAA záznamů je udělané zpětně kompatibilně. Tj. CA má povinnost získat CAA záznamy pro danou doménu. Pokud žádný CAA zázname nenajde, znamená to, že vlastník domény CAA záznamy nepoužívá a CA vydává certifikát jako v době bez CAA. Jakmile CA najde nějaký CAA záznam, znamená to, že je vlastník domény používá – a CA musí ověřit, že mezi CAA záznamy najde ten „svůj“.

Je nepravděpodobné, že by nějaká velká autorita neověřovala CAA záznamy a nepřišlo se na to. Třeba Let's Encrypt v roce 2020 revokovala miliony certifikátů, když se přišlo na to, že v procesu validace CAA záznamů měli díru, která umožňovala vystavit od LE certifikát i nějakou dobu po té, co byl CAA záznam LE z DNS odstraněn.