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/obcerstvenou verzi distribuujete?
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.
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.“
1) raceji si zjistit, co to je RFC (tim minim co ta zkratka znamena)
2) bez ohledu na to, zejimalo by mne, japa sem lezou useri ... kdyz neverej tomu co je v DNS = ne, dane s dnssec nema spolecneho zhola nic.
3) certifikaty v soucasne podobe zadnemu mitm nebrani, naopak ho podporuji. Temi utocniky jsou samy tzv "duveryhodne" autority, pripadne provozovatele DNS potazmo hostingu. A pochopitelne nejen.
1. Vím velmi dobře, co ten název znamená. Taky ale vím, že původní zkratka se vyvinula před více než padesáti lety a ty dokumenty se od té doby staly internetovými standardy. Zkratka zůstala, stejně jako spousta jiných pojmů, které už dnes nedávají původní smysl, ale užívají se.
2. DNS není příliš důvěryhodný zdroj dat už z principu. Data se posílají nešifrovaně, sbírají se z různých zdrojů a ukládají do různých keší. Ty se navíc dají třeba otrávit a nacpat do nich falešné informace. Takže pokud chcete mít skutečně ověřená data, musí je zdroj podepsat a k tomu slouží DNSSEC. Stále platí, že DANE je postaveno na ověřeném přenosu dat pomocí DNSSEC.
3. Tohle by chtělo lepší vysvětlení. Jak si mám přesně představit, že certifikační autority nebo DNS na mě útočí pomocí MitM? Jak ten útok zhoršuje to, že uživatel očekává od serveru platný certifikát?
Racej si o tech RFC neco precist :)
A teda nevim, jak funguje vas resolver - ale ten muj DNSSEC overuje, a kdyby nedejboze nekdo po ceste odpoved pozmenil, tak se o tom dozvim.
CA i provozovatele DNS jsou jakoze dost po drobnohledem na to, aby nejake MITM vubec zkouseli. Ano, par incidentu s CA bylo, ale reakce byla razna a rychla. Rozhodne neplati, ze by se to delo na denni bazi.
U DNSSEC (ono to souvísí i s DANE) řešíme praktický problém, ta validace je dobrovolná, u klienta (myslím tím stranu aplikace, která chce využívat data z DNS) se může ztratit informace, že vše je podle DNSSEC validní, záleží na nastavení OS.
Ano, pro konkrétní aplikaci, která mi běží na serveru to zajistit umím, ale pro aplikaci, která běží na osobních počítačích/tabletech/mobilech?
Ano, a proto DANE ma DNSSEC za mandatorni. Prave proto, ze samotny DNSSEC je volitelny. A cele overovani ruznych veci, pocinaje platnosti TLS certifikatu... je dobrovolne, zeano :-)
Validovat samozrejme muze i koncova stanice. A nebo jsou tu techniky, kterak zabezpecit tu cestu mezi resolverem a koncovou stanici (DoT, DoH). To je holt uz o politice/duvere, kterou si nastavi admin...
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.
Certificate Transparency ovšem netuší, kam se uživatele připojují. To ověřování probíhá na počítači uživatele, protože potvrzení o vystavení certifikátu v logu (SCT) musí uživateli dodat už server při navazování spojení. Prohlížeč se rozhodně nikam nepřipojuje, aby se ptal, jestli je ten certifikát veřejný. Má všechny potřebné informace už u sebe a nic nemusí prozrazovat. Viz článek Certificate Transparency: vydávání certifikátů pod kontrolou.
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.
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
"SPOF je defacto kazda CA sluzba"
Takze jen nevis, jak to (teoreticky) ma fungovat ... Protoze CA k overeni certifikatu/sluzeb vubec potreba neni.
A napadnout to jde zcela trivilane, kdyz mas na jednom miste vsechny certifikaty, tudiz i klice, tak si je staci stahnout ze? A instantne ti kompromituju kompletne celou infrastrukturu. Nejak si nedovedu predstavit japa bys to chtel resit ... teda krom toho ze vemes sekeru a vsechno rozmlatis.
Klíče nemusejí tímhle kanálem vůbec téct, ty servery si mohou stahovat z centrálního bodu jen aktuální certifikáty, což je veřejný dokument a jeho únik tuží nevadí. Soukromé klíče se nemusejí při obnově certifikátu vůbec měnit, tudíž je není třeba nijak znovu přenášet a certifikační server je nemusí ani nabízet. To by bylo skutečně potenciálně nebezpečné, ale potřeba to vůbec není.
bez prezdivky ...: Proč tu pořád píšete o věcech, o kterých vůbec nic nevíte?
Certificate transparency neumožňuje nijak šmírovat uživatele, protože důkaz o tom, že je certifikát na nějakém CT listu, je vložen přímo do certifikátu.
Když máte na jednom místě certifikáty, vůbec to neznamená, že máte na jednom místě i privátní klíče. privátní klíč klidně může být neexportovatelný na nějakém HSM, třeba může mít každý server vlastní HSM. Jediná věc, ke které potřebujete privátní klíč při vystavování certifikátu, je podpis žádosti o certifikát. Žádost klidně může vytvářet koncový server, který k sobě má připojen HSM. Vytvořenou žádost pak předá infrastruktuře pro správu certifikátů, ta zajistí vystavení certifikátu a ten zpřístupní koncovému serveru. Takže celá ta infrastruktura pro správu certifikátů klidně může pracovat jen s žádostmi a certifikáty, žádné privátní klíče mít nemusí.
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ý.
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.
Jediné riziko, které u bezestavového systemu vidím, je únik privátního klíče účtu ACME. Ale to je průšvih sám o sobě, držitel ACME účtu může například revokovat všechny vydané certifikáty, nebo vydávat certifikáty pro dříve ověřená jména během "Authorization Reuse Period." Nezdá se mi tedy, že by použití bezestavového režimu nějak zásadně změnilo bezpečnost celého systému.
Nepřišel jsem na to, jak mít "službu vyhrazenou na ověřovací soubory," která bude stejně robustní jako zbytek clusteru jinak, než že ta služba bude běžet přímo na tom clusteru (a to znamená rozkopírovávat obsah).
Nemusí dojít k úniku privátního klíče. Všechny ty uzly v clusteru si mohou nechat vystavit certifikát za jiný server v clusteru. Někdy to může být OK, protože jsou si všechny uzly clusteru rovny. Někdy to nemusí být OK, protože ty uzly clusteru mohou mít různé funkce, třeba různé aplikace, a může být nežádoucí, aby jedna aplikace mohla vystavit certifikáty patřící té druhé aplikaci.