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?
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.“
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.
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
"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ý.
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.
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.
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.