Názory k článku Let's Encrypt komerční certifikáty ze státní správy nevytlačil

Nasazení Let's Encrypt závisí na provozovaných systémech. Často se stává, že korporátní aplikace specificky počítají s roční manuální výměnou bez poskytnutí rozumného API. Narazil jsem na to minimálně u Cisco řešení, propojení s Microsoft cloud prostředím (např. ADFS), a řešení využívající Microsoft produkty ať už on-premise nebo interagující s cloudem (např. ADFS). Překvapilo mě, že load-balancer od F5 Networks stále nemá nativní podporu, ale naštěstí poskytuje rozumné API pro integraci.

Většinou, když se bavím s dodavateli, tak autoritu neznají a s automatizací výměny certifikátů v systémech nepočítají. A je jedno zdali je to velký/malý systém. Tato situace platí už od roku 2016 a vždy nás tlačí do standardního certifikátu. Už se to naštěstí pomalu zlepšuje se zkracováním platnosti certifikátu. Takže v článku uvedeného výčtu systémů bez Let's Encrypt bych to viděl spíše tak, že u většiny je řešení plně pod správou dodavatele, který bude mít na starosti výměnu certifikátu a ten jde cestou minima práce.

Ve snaze o nasazení pak je nutné do veřejných zakázek explicitně uvádět, že součástí dodávky je i řešení automatizované výměny certifikátů od Let's Encrypt.

Za mě použití Let's Encrypt není o penězích, ale hlavně snížení zátěže spojené s obsluhou výměny certifikátu. Náklady na všechny veřejné certifikáty v organizaci se bude pohybovat v řádu desetisíců korun za rok, to je v celkovém rozpočtu zanedbatelné. Ale člověk, který má systém na starosti si kromě monitoringu neúspěšné obnovy nemusí hlídat čas obnovy, zajistit vydání nového certifikátu a následně jeho úspěšné nasazení. Opakovaně se nám stalo, že s výměnou certifikátu u některých systému byly problémy (např. u SAPu, ADFS).

Nasazení bezplatné autority je tak mravenčí práce, kdy se v lepším případě použije jen reverzní proxy s certbotem a v tom horším se doplní o skript manipulující s certifikátem a interagující s více systémy. Takto se nám povedlo zredukovat počet komerčních certifikátů na tři a po nasazení F5 to nejspíše bude jen jeden.

V takových situacích se často zapomíná (nebo neví), že je lepší kontrolovat veřejný klíč v tom certifikátu. Ten se při vystavení nového certifikátu nemusí měnit a Let's Encrypt ho ani ve výchozím stavu nemění. Prostě se jen podepíše ten původní klíč a vystaví se certifikát s novou platností.

Čili když někde potřebuji pinovat nějaký element, je mnohem lepší k tomu využít přímo svůj veřejný klíč, než proměnlivý certifikát.

Problém té domnělé vyšší důvěryhodnosti OV nebo EV certifikátů je, že neexistuje vazba mezi konkrétním doménovým jménem a povinností mít u něj vyšší stupeň certifikace. Software tedy OV nebo EV nevynucuje (nemá jak) a uživatel ho taky nikdy neřešil. Třeba PayPal chvíli EV měl, pak ho vyměnil za DV a po nějaké době se zase vrátil k EV. Uživatelé to neřešili a ani si toho nevšimli. Nevznikl žádný humbuk, nikdo o tom nepsal.

Proto nedává OV a EV příliš smysl. To je taky hlavní důvod, proč prohlížeče přestaly tu informaci zobrazovat. Další je, že se ukázalo, že je možné si v jiné zemi pořídit firmu PayPal a pak si na její jméno nechat ten EV certifikát vystavit.

To je jen jízda na mrtvém koni způsobená setrvačností státní správy.

Neni lepsi resit pricinu - tzn. proc takova vec takovy "bastl", ze je problem ten certifikat vymenit a ukon automatizovat - nez brecet nad nasledky zkracene platnosti? :-) Doba platnosti na schopnost vymenit certifikat nema vliv, realne ta rucni prace vede k tomu, ze pak mate sluzby i cele hodiny nefunkcni jen proto, ze nejaky matlal nekde "nestihl" rucne ten certifikat vymenit.

Tyhle problémy většinou jsou u specializovaných jednoúčelových věcí kde dodavatel na váš požadavek háže bobek, sám tu automatizaci nedobastlíte a ke konkurenci nepřejdete protože alternativy nějak nejsou.

A jak to vypadá s návrhem zkrátit dobu platnosti certifikátu? viz https://www.root.cz/clanky/google-chce-omezit-platnost-certifikatu-na-90-dnu-zmena-zrejme-prijde-brzy/

Neumím si představit, že budu co 3 měsíce nasazovat nový certifikát - jsou místa, kde automatizaci prostě nelze použít - to v práci nebudu dělat nic jiného, sorryjako. :-)

Dokazu si takovou vec i predstavit, na druhou stranu takova vec urcite nepotrebuje byt vystavena primo do internetu, notabene naprimo iteragovat s uzivatelskym prohlizecem. Pokud k tomu "vyrobce" pristupuje jak popisujete, tak certifikaty budou ten posledni problem - tech moznych bezpecnostnich rizik bude s urcitosti blizici se jistote mnohem vic a pak je zadouci takovou vec maximalne izolovat. Vime jak tyhle "veci" funguji - pred dvaceti lety nekdo neco vyrobil a od te doby na to poradne nesahnul - a zadny certifikat to nezachrani, kdyz to ve finale pouziva sifry z muzea.

Komerční certifikáty v dnešní době jsou velký fail, jejich hlavní benefit jsou dárečky pro nákupčí na Vánoce a pocit tepla a bezpečí u zákazníka, který ale nemá nic společného s realitou.
Na speciální zacházení se zákazníky dojel třeba Entrust. Zákazník (typický Entrustu) totiž není schopen vyměnit certifikát v případě potřeby dost rychle a spoléhá tedy na nadstandardní vztahy, protože za něj platí - správně by totiž certifikát WebPKI vůbec neměl používat pokud ho nedokáže ihned vyměnit. Představte si, že jste velká firma co má těch certifikátů stovky nebo tisíce, všechny od komerční CA typu Entrust a máte je do 24h všechny orotovat. "Zákazníkovi přestane fungovat IT" není platný argument, a pokud se naštve moc ajťáků tak CA moc dlouho ve WebPKI trustech nepobyde. Kdo chce ať si najde komponentu CA v Mozilla Bugzille, je to moc hezké čtení (Technický ředitel Entrustu tam lhal nebo psal nicneříkající žvásty, co mu projdou na prezentaci v korporátu, technici se ale nedali a poslali ho do... a business není).
Pro neveřejné systémy by taková firma měla používat vlastní PKI (nebo si ho na klíč koupit, třeba jako SaaS), ale u veřejných domén není omluva nepoužívat automatické vydávání třeba přes ACME, respektive v souladu s pravidly se to jinak použít ani nedá.

Další kapitolou failu je spoléhání se na konkrétní doménu kvůli phishingu. To je v dnešní době fail způsobený přihlášovaním jménem a heslem místo WebauthN/FIDO, které se nedá phishovat, nebo alespoň zpátečnicky pomocí x509 certifikátu, nebo alespoň nějakou rozumnou (ne SMS) 2FA metodou kde její vypnutí není rutina, ke které stačí heslo a jeden telefonát na poskytovatele služby. Šílené politiky hesel, technicky impotentní přihlašování pomocí nich (bez KDF) a neustálý rebranding tomu rozhodně nepřidává. Škoda, že eObčanky nemají NFC a PIV applet nebo FIDO s atestací, třeba se jednou dočkáme, do té doby by to mohlo suplovat mojeID.

Ale to by to někdo musel chtít řešit, a vendoři to rozhodně nejsou, těm naopak proprietární závislosti vyhovují. Tlak na změnu by měly vyvíjet hlavně pojištovny, co hradí způsobené škody, ale tam se na Vánoce objeví úplně stejné dárkové taštičky od stejných vendorů...

Pokud někdo spoléhá na "zveřejnený" certifikát (Certificate pinning), tak nemá ve veřejném PKI vůbec co pohledávat. Chápu, děje se tak na základě 20 let starých směrnic (které tiše drží při životě právě vendoři), ale to není omluva.

Naprosto tedy vítám zkrácení platnosti certifikátů, snad to konečně rozhýbe zkostnatělé IT a postupy a alespoň část těch failů to silou napraví.

27. 2. 2025, 11:06 editováno autorem komentáře

Bezpečnost často nelze nařídit, často je možné akorát dát možnost chovat se bezpečně. Ostatně s vaším přístupem můžeme zrušit i HTTPS – jsou uživatelé, kteří jdou na web i přes HTTP, tak podle vaší logiky zrušme HTTPS všem. Protože HTTPS je dnes stále jen možnost, ne povinnost.

Obyvatelé ČR budou ponejvíce komunikovat se státní správou ČR a vlajku ČR znají. Takže vlajka ČR a vedle toho nápis „Ministerstvo obrany České republiky“ by drtivou většinu uživatelů ujistil, že jsou na správném webu. Když mají správný certifikát pro army.cz, ví většina obyvatel ČR houby o tom, zda je to oficiální web MO ČR. Ano, zrovna MO už je na gov.cz, ale tam nebude zdaleka vše ani z veřejné správy – třeba obce tam předpokládám nebudou. Takže třeba praha.eu – je to správná doména? No a pak je tu komerční sektor, třeba u internetového bankovnictví je docela důležité vědět, že komunikuji opravdu s bankou – což dneska znamená, že si musím pamatovat její doménu. O platebních branách ani nemluvě, ty snad tajně soutěží o to, která bude mít obskurnější doménu.

To, že doména nemůže vyžadovat vyšší stupeň certifikace, podle mne není problém. Smysl OV certifikátů by byl v tom, že by se mi v prohlížeči zobrazilo jméno instituce, které byl certifikát vydán (tedy to, co dělaly EV certifikáty). Já jako uživatel pak právě nemusím znát doménové jméno, ale když vidím, že byl certifikát vystaven pro organizaci „Komerční banka a. s.“, nemusím vědět, zda mají bankovnictví zrovna na doméně mojebanka.cz nebo tvojebanka.cz nebo kb.cz, ale je pro mne důležité, že komunikuju opravdu s webem té banky.

Proto by u OV certifikátů bylo důležité zobrazovat ještě jurisdikci, podle které byl ten subjekt ověřen. Podle mne by dávalo velký smysl, kdybych u certifikátu vydaného podle eIDASu viděl v prohlížeči vlaječku EU a u toho jméno subjektu, kterému byl certifikát vystaven (a možná ještě vlajka konkrétního státu, aby se dala odlišit třeba česká a slovenská KB).

Současný stav, kdy všechny certifikáty v prohlížečích vlastně fungují jako DV, není dobrý, protože to vyžaduje, aby uživatel přesně znal doménu. Třeba ten PayPal – když u OV/EV certifikátů nejsou vlaječky států, dá se to obejít registrací firmy PayPal na nějakém ostrově s benevolentní legislativou. Ale ještě jednodušší je to s doménou, zaregistrovat si třeba paypal.eu nebo paypal.money, nebo dokonce jen pay-pal.com. Něco z toho možná vlastní skutečný PayPal, ale určitě se dá najít spousta domén, které PayPal nevlastní – a které budou vypadat dostatečně věrohodně i pro zkušené uživatele.

Podle mne to odstranění z prohlížečů bylo zbrklé – místo aby vyřešili problém, že je vedle subjektu potřeba zobrazovat i stát, přestaly to zobrazovat úplně. Chápu argument, že je na mobilech málo místa – ale přes web se toho řeší čím dál víc a představa, že uživatel bude znát domény všeho, co používá, je prostě úplně mimo.

A zrovna ten PayPal je dobrý příklad, protože v současné době má PayPal problém s tím, že se dá posílat phishing přímo přes systémy PayPalu. Takže ty e-maily mají podepsané hlavičky, 100% vzhled, protože je to generované přímo systémy PayPalu. Pokud někdo dostane třikrát takovýhle phishing vedoucí na doménu paypal.com a počtvrté dostane stejně vypadající e-mail, který povede na doménu paypal.eu, může se na to nachytat pozorný uživatel.

Mně nešlo o žádnou ikonku, ale o vlajku státu, pod jehož jurisdikci patří držitel certifikátu. Protože mně jako uživateli internetového bankovnictví je úplně jedno, jaké logo má zrovna moje banka, já potřebuju vědět, že komunikuju s institucí „Fio banka a. s.“ registrovanou v České republice. Protože při komunikaci s bankou mi hrozí dvě věci – že budu místo s bankou komunikovat s firmou „Šťastný hacker & syn“, nebo že budu komunikovat se subjektem, který se úplně náhodou jmenuje „Fio banka a. s.“, akorát že je registrovaný v Indonésii. Ten první problém uměly řešit EV certifikáty (a měly to řešit OV certifikáty, kdyby CA nebyly nenažrané), to druhé nejde na globálním internetu řešit jinak, než že uživateli zobrazíte, z jakého státu je registrace daného subjektu. Protože státy, které nás zajímají, si už umí zařídit, aby podvodný subjekt náhodou pojmenovaný úplně stejně jako banka nebyl registrován.

Nebylo to zbrkle. Je to pragmaticka reakce na standardni a praxi prokazane vetsinove chovani uzivatelu, ktery je dost casto jedno, co v tom adresnim radku vlastne je - vc. URL. Ano, je tu par nerdu (vas nevyjimaje), co na to koukne...

Dost naivni (opet spise nerdovska) je i predstava, ze lidi si budou v hlave nosit "spravnou" jurisdikci, ze ktere je sluzba poskytovana a podle toho kontrolovat nejake vlajecky.... :-)

Někdy ta automatizace není možná i proto, že máte EV certifikáty, které je potřeba ručně potvrzovat, což ve firemním prostředí tu výměnu prodlouží i na více než týden (a nasazují se po datacentrech). Ten proces je zvládnutelný, bezvýpadklový, ale poněkud zdlouhavý.
Navíc: pokud za ty certíky platíte, firma to rozhodně nesvěří nějakému automatu - někdo to musí schválit.
Pak dávají certifikáty s roční platností smysl.

Jenže vy se na to díváte naruby. Není potřeba, aby uživatel zkoumal každý web, který navštíví. Uživatel potřebuje, aby když navštíví pár webů, které potřebuje mít spojené s konkrétní institucí, mohl si ověřit, že je to opravdu ta instituce. Pro občany ČR budou těmi institucemi instituce české veřejné správy, české banky, pojišťovny a podobné instituce. Tedy vše subjekty registrované v ČR. Jestli má někdo peníze ve Švýcarské bance, holt si buď zjistí její doménu, nebo se naučí poznat Švýcarskou vlajku, nebo to holt riskne bez ověření, jako dnes.

Vetsina tehlech "postupu" v realu vede k tomu, ze sluzba klidne cele hodiny nefunguje, jen proto ze nekdo nekde se musi neco rucne posolichat.

No, to se dostavame k tomu, jestli je cely proces je takto vubec spravny. Rucni schvalovani je zdroj chyb. Nekdy je lepsi zmenit cely proces, nez vymejslet rovnaky na vohejbaky. EV neni zdrojem vyssi bezpecnosti, to je jen chimera. Tech CA, kterym i vas prohlizec duveruje jsou mraky a jsou z ruznych koncu sveta. Podchytit nejaky podvrh nemusi byt vubec snadne - zvlast kdyz bude takovy utok treba cileny jen na vybranou skupinu uzivatelu - kdy navenek vsem ostatnim se zobrazi neco jineho (klidne per-source IP). Spolehat se na nejake "zelene zamecky" fakt nedava moc smysl, kdyz takovy certifikat muze vystavit treba nekdo z Ciny. Cely koncept EV je slepa cesta, prave proto ze tech certifikacnich autorit je tolik.

Nařídit lze, jen to nemá požadovaný efekt (papír snese všechno).
Ale jsou prostředky, jak jí alespoň trochu technokraticky vynutit.

Vlaječka a nápis rozhodně ničemu nepomůžou, podobné logo a podobný název validací projde a jsme tam kde jsme.
Problém je právě v tom spoléhání se na domény, ale způsobený je tím, že jdou kredence phishovat.
HTTP+WebauthN by bylo svým způsobem bezpečnější (pro účely autentizace) než HTTPS a heslo.

Idea možná hezká, ale když jsem viděl jak to ověřování funguje (Ind volá na česky mluvící klientskou linku - pro něj z veřejných zdrojů ověřené číslo spojené s firmou - a světe div se, OV certifikát je potvrzen, i když klientská linka prokazatelně nevěděla o co jde) tak jsem rád že to je z prohlížečů pryč.

Já jsem ale nepsal o logách, ale o vlajkách států. A název „Fio banka a. s.“ už si v ČR fakt nezaregistrujete, a kdyby si někdo zaregistroval třeba „Fio baňka a. s.“, tak ho to jednak vyjde docela draho, jednak bude snadno dohledatelný.

S kým komunikujete potřebujete vědět, i když se vůbec nikam nepřihlašujete. Když se chcete podívat, na jaké číslo účtu máte zaplatit daň, přihlašovat se nikam nemusíte – ale nebýt v tu chvíli na webu Finanční správy nýbrž na webu podvodníka může být docela drahé.

Ona je možná chyba nasazovat LE certifikáty tam, kde to není z podstaty veřejné. Jednu dobu jsme tady měli také vlnu, že se LE cpal všude, dnes spokojeně jedeme na vlastním CA a tam je potřeba veřejný přístup se strčí brána (reverzní proxy, terminátor), který má LE na jedné straně a na druhé straně validuje interní CA. Jak píšeš, strčit na F5 a necpát nikam interně.

Pokud jde o SOHO krabičky (routery a podobně), které jsou oddělené a servisují se ručně na místě, tak u nich nefungovaly veřejné certifikáty nikdy. Tam asi asi vhodnější použít api a mít vlastního klienta, agregátor (mobilní apku, endpoint někde v internetu), který komunikaci bude zprostředkovávat.

Ja chapu vasi zamecko/vlajkovou euforii, ale jak uz tu poznamenal mj. i Petr, je to jizda na mrtvem koni - ktera ma jen flikovat to, ze uzivatele pisou sve jmena/hesla, kam nemaji. Systemove a v industry davno prijate reseni je se hesel... badum tss... proste zbavit :-) A ono dnes postavit i s opensource reseni, kde uzivatel zadne heslo nepotrebuje neni zas takova magie. Kdyz se nechcete crcat s autentizaci, integrace MojeID (nebo treba Google ci Apple ID) take neni zadna cerna magie. Resit bezpecnost skrze nejake ikonky v adresnim radku a spolehat na to, ze uzivatel neco neprehledne je... proste mrtvy kun.

Kde probuh pisu neco o ruseni HTTPS? Transport je treba zabezpecit, ale tim to zdaleka nekonci. Nelze spolehat na nejake zelene zamecky a vlajecky s tim, ze pak se tam daji v klidu busit jmena a hesla. Ty banky to mimochodem davno resi... tak, ze hesla postupne proste a jednoduse odbouravaji. Heslo je stejny prezitek jako EV certifikat a i na gov.cz se dnes bez hesla prihlasite i s uzitim statnich prostredku.

Další důvod může být to, že někde (celní správa, mfčr u hazardu) každý certifikát oznamují na webu, zveřejní ho tam předem, a (jak jsem pochopil) čekají že druhá strana kontroluje přímo konkrétní certifkát, ne jen root jeho chainu. Nevím jestli to tak dělat "musí" nebo to je jen zvyk, každopádně to asi automatizaci komplikuje.

27. 2. 2025, 08:57 editováno autorem komentáře

Tož vzhledem k tomu, že součástí certifikátu mohou být i různá nepovinná data, tak by nejspíš nebyl problém tam přihodit třebas ikonu 32x32 bodů ve formě Base64 dat, a nechat si to podepsat; u OV/EV certifikátu by mohlo být zaručené, že kontrola validovala i skutečnost, zda máte k danému vzoru práva (ochrannou známku).
Nicméně soudím, že reálně by to zneužitelnost nesnížilo.

Jenže to zobrazování vlaječek by vedlo pouze ke zmatení uživatelů, protože je spousta firem s registrací v jiné zemi, než ve které působí: na Kypru, v Lucembursku, na Kajmanských ostrovech...
Naproti tomu by k nim mohl existovat v Česku registrovaný hackerský subjekt...

Problém je v tom že když se chcete zbavit hesel tak potřebujete mít na straně uživatele nějaké autentizační zařízení a je tu relativně velká skupina lidí která tu extra techniku prostě nechce.

To jsem reagoval (aspon myslím) na Filipa Jirsáka.

Hesla odbourávají pomocí aplikace, která stále vyphishovat jde. Teoreticky na ní přijde i převod z účtu na účet podvodníka, jenže ten si přidá vlastní autentizátor a původní odebere. Takže je to o trochu lepší než hesla, ale ne o moc.

No a nebo se ho proste nebudete ptat a date mu to befelem. Banky to tak ostatne delaji... moc s vami tu diskuzi o tom, jake autentizacni prostredky pouzijete nevedou. Zrovnatak se vas moc nebude ptat ani Google ci Microsoft. Proste to tak bude, zarid se. Jsou sluzby, co uz MFA explicitne vynucuji.

Vsak ja reaguju na nej, ne na tebe :-) A ano, souhlasim ze ty (proprietarni) aplikace nejsou nelepsi reseni, idealni je se posunout smerem ke standardizovanym resenim - ktere ale preci uz davno k dispozici mame. Jasne, i HW FIDO2 token / TPM device (jak funguji treba passkeys u Apple nebo i novejsich Androidech) muze byt nejak zranitelne, ale lepsi je to podle me o dost...