Názory k článku Let's Encrypt zjednoduší práci s DNS, bude stačit přidat záznam jen jednou

Hmm, mě ohledně zkracování maximální doby platnosti zajímají 2 věci:

* Proti jakým konkrétním útokům se bráníme? Nepamatuji se na žádné vážné incidenty, které by se týkaly zneužití certifikátů starších 45 dnů.... Drtivá většina útoků zneužití domény trvá jen krátce - v rámci hodin, pak je omezí např. blacklisty v prohlížečích, které jsou celkem rychlé a účinné i teď a budou vždy rychlejší, než plánované 7-denní certifikáty.

* Proč nutit ke krátkým certifikátům všechny? Nestačilo by jen přidat do nabídky krátké certifikáty? Ti, kteří o ně stojí by na ně přešli a ti, kterým by to způsobilo jen komplikace by zůstali na stávajících.

Ano, dokáže někdo s patřičnými znalostmi vysvětlit, proč se obecně tak tlačí na zkracování platnosti certifikátů?
Předem díky.

Těch důvodů, krom, že ta revokace "nefunguje" je vícero. Zvýšení bezpečnosti, podpora automatizace, rychlejší reakce na změny a hrozby, lepší revokační model a v neposlední řadě nástup kvantových počítačů a hrozba dešifrování klíčů (real problém 2029+).
Termíny zkracování tady v článkách nebo i zde https://www.sslmentor.cz/napoveda/ssl-info-platnost
Zkracují se i CODE od 03/2016.
CA se s tím už smířily a podporují i automatizaci ACME nebo mají vlastní robustní řešení.

Petře, nedělej si tu reklamu...

Za mne jde o útok, kdy někdo přijde o vlastnictví domény, ale může mít ještě rok (u ročních certifikátů) certifikát, který tvrdí, že dotyčný je vlastníkem domény. Představte si třeba doménového spekulanta, který prodá nějakou doménu, ale ještě rok k ní může mít certifikát. Nebo soudní spor o nějakou značku, soud nakonec rozhodne, že současný vlastník domény jí musí přestat používat a předat majiteli ochranné známky – a ten původní majitel poražený u soudu bude mít ještě rok platný certifikát pro tu doménu. A nový majitel domény nemá jak ty původní certifikáty zneplatnit (i kdyby je zneplatnil u CA, zdaleka ne všichni používají CRL).

Dobre, chapu, ale pokud nekdo prijde o vlastnictvi domeny, prijde i o kontrolu nad ni, ne? Tj. DNS nasmeruje jinam, zvaliduje novy certifikat. A k cemu bude puvodnimu majiteli stary certifikat, kdyz jej nemuze pouzit, protoze DNS smeruje jinam?

Doménové certifikáty se používají právě pro případ, kdy by komunikace směrovala jinam, než co si přeje majitel DNS. Buď by někdo zfalšoval DNS odpověď, pokud doména nepoužívá DNSSEC. Nebo by někdo přesměroval provoz na úrovni IP provozu (někdo, kdo je po cestě paketů).

Původní majitel tak může dělat MITM. To je přece důvod, proč nějaké certifikáty vůbec používáme, a proč by nebylo dobré, aby měl kde kdo certifikát na cizí domény.

Hlavní důvod je, že nefunguje revokace certifikátů (OCSP apod.).
- pokud při nedostupnosti OCSP bude certifikát považován za nevalidní, zavádí to single point of failure
- pokud při nedostupnosti OCSP bude certifikát považován za validní, stačí v man in the middle útoku zablokovat url OCSP služby

Jako možné řešení jsou právě krátkodobé certifikáty, tedy s platností cca týden.

Pomalu k tomu celý ekosystém směřuje

"Hlavní důvod je, že nefunguje revokace "

Kolik si kdy revokoval certifikatu?

Pokud bude po expiraci cert povazovan za nevalidni, je to SPOF jak vysity. Ostatne, zmenit datum neni povazovano za kritickou akci kterou by nemoh udelat kdokoli.

I pri 90denni platnosti sem osobne videl desitky pripadu, kdy se cert z ruznych duvodu neobnovil vcas. Banky, ktery si na to platej extra lidi, neumej certifikat obnovit vcas ani kdyz ma platnost v rocich.

Kolik si kdy revokoval certifikatu?
Revokace nefunguje nikoli proto, že by nešlo certifikát revokovat. Nefunguje proto, že se ve spoustě případů neověřuje, zda certifikát revokován nebyl.

Pokud bude po expiraci cert povazovan za nevalidni, je to SPOF jak vysity.
Cože, jaký SPOF? Jinak samozřejmě po expiraci je certifikát považován za nevalidní a je to tak v pořádku.

Ostatne, zmenit datum neni povazovano za kritickou akci kterou by nemoh udelat kdokoli.
Změnit datum kde, na počítači? Pokud vám útočník dokáže na počítači změnit datum, to, že bude váš prohlížeč důvěřovat expirovanému certifikátu je ten nejmenší problém, který máte.

I pri 90denni platnosti sem osobne videl desitky pripadu, kdy se cert z ruznych duvodu neobnovil vcas. Banky, ktery si na to platej extra lidi, neumej certifikat obnovit vcas ani kdyz ma platnost v rocich.
To je ovšem problém těch, co to neumí a neumí si to pohlídat. Kvůli tomu ovšem nemusíme ohrožovat bezpečnost všech.

Jasne sem se ptal, kolik kdo kdy revokoval certifikatu. Neumis cist?

Zmenit datum muze kazdy jeden uzivatel libovolnyho desktopu.

Jiste, jirsak je v praci 24/7 a dovoleny si zasadne nebere. Celou tu dobu travi vyhradne a pouze tim, ze vartuje zda se nekde neco nepodelalo, a jeden ze 1589897 certifikatu se zrovna neobnovil.

Hurá konečně bude použitelné ověření přes DNS aniž bych musel neustále hlídat změny v nějakém externím api.

<rejp> tak a teď už jen poslední krok, změnit ten DNS record na TLSA, a kruh se uzavřel </rejp>

Nerozumím, jaké změny externího API musíte neustále hlídat.

Chápu potřebu dát do DNS ověřovací token jen jednou, i když stejná potřeba může být i pro HTTP. Doufám, že současná metoda DNS-01 bude i nadále podporována. Protože na jednu stranu se zkracuje doba platnosti ověření domény, na druhou stranu se tímhle způsobem to ověření prodlouží na nekonečno.

Je dobře, že Let's Encrypt podporuje v DNS CAA záznamech rozšíření validationmet­hods, takže si každý může řídit, které metody validace povolí.

> Nerozumím, jaké změny externího API musíte neustále hlídat.

Pravděpodobně API jeho poskytovatele DNS, pro automatické nastavování záznamů.

Ano, je tam i možnost to delegovat na vlastní DNS server. Ale je to také trochu opruz, najednou muset provozovat DNS (byť jednoúčelové ACME klientem).

Pravděpodobně API jeho poskytovatele DNS, pro automatické nastavování záznamů.
To se opravdu děje, že by nějaký poskytovatel DNS měl API tak často a rychle staré verze přestal podporovat?

Já používám primárně DNS validaci certifikátů, protože to používám i pro weby, které nejsou vystavené do internetu – a nikdy jsem s tím nemusel řešit nějaký problém. A moc si nedovedu představit, jak by vznikl – průběžně aktualizuju webový server, který má ACME protokol implementovaný v sobě, včetně připojení na mnoho DNS poskytovatelů. Předpokládám, že případná změna API bude probíhat nějakou dobu, spíš roky nebo alespoň ne úplně málo měsíců, za tu dobu bude ta změna implementována do mnou používaného softwaru a dostane se ke mně v rámci běžných upgradů.

Alebo API daneho poskytovatela vacsina ACME klientov nepodporuje vobec.

Poskytovatel je Hurricane Electric.

IMHO by to chtělo postavit tuhle vrstvu ochrany víc od základů. Jistě by se dalo spousta funkčních a efektivních postupů, které by nezatěžovaly uživatele. Myslím, že je tu velký prostor pro optimalizace. A k tomu by byla potřeba tvrdá data.

Jestliže jsou bezpečnostní problémy primárně s novými doménami, tak by mohly být v režimu platnosti certifikátu jen na pár hodin, nebo by mohly mít úplně jinou kategorii, a browsery by se k nim chovaly opatrněji.

U nových domén ale není problém s certifikáty. Certifikát k té doméně má její vlastník. Problém je to, co se na té doméně provozuje – a to s certifikáty vůbec nijak nesouvisí.

Ja mam v k8s clusterech platnost pro certifikaty jen 24 hodin. O nic se nestaram... Certification-manager je obnovi sam.

Takze mame vsude bezet k8s? /s

A s ACME mate jaky problem? :-) Bezi to na cemkoliv...

A co když neobnoví? Co když nějaký průšvih u LE? U takhle krátké platnosti máte hrozně krátkou dobu něco řešit (kolik tam máte, 8h left?). Nejlíp, když se bez platného certifikátu nepřihlásíte na VPN, nebo se Vám bez platného certifikátu rozsypou nějaký clustery.

24h... pokud nemate on-call 24/7 tak pres víkend máte smůlu. A musíte se spolehnout na monitoring, validaci monitorovacích testů a monitoring monitoringu.
Proto se dávají delší expirace.
On ten oncall je pro firmu/SLA kvůli tomuhle zatraceně drahý.

7. 12. 2025, 09:15 editováno autorem komentáře

V článku je to lehce nakousnuté... Máte někdo nějaký tip, jak pohodlně monitorovat stav a platnost certifikátů, když se člověk stará o více různých domén?

Že by nejaký jednoduchý script s curl a openssl?

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Treba takto, zbytek si uz můžete zaobalit jak chcete

Standardní check_http (z Nagios-plugins, používá ho třeba icinga) má na tohle explicitní volbu.
https://nagios-plugins.org/doc/man/check_http.html

-C, --certificate=IN­TEGER[,INTEGER]
Minimum number of days a certificate has to be valid. Port defaults to 443
(When this option is used the URL is not checked by default. You can use
--continue-after-certificate to override this behavior)
--continue-after-certificate
Allows the HTTP check to continue after performing the certificate check.
Does nothing unless -C is used.

4. 12. 2025, 15:04 editováno autorem komentáře

jj, to jsou ty zkusenosti, certifikatu se totiz dozaduji vyhradne webovy servery, a vsechny jsou vzdy dostupny z jednoho mista, zcela verejne ....

A kazdej jeden ma svyho vyhradniho admina, kterej 24/7 vartuje, jestli se ten kram vcas obnovil, protoze za hodinu uz bude expirovanej ....

A ono je takový problém si (klidně na tu samou icingu) jako zapnout nějakej nginx na localhostu, a do něj ten automat, co to provisionuje certy na ne-webový věci nechat provisionovat paralelně i do něj. Navíc ta icinga vůbec nemusí bejt ani venku, že ano.

A k tomu vartování, Vy tam nemáte nějakej ten NOC (v tomhle případě klidně i indiánskej, i když je to jinak obvykle o nervy), kterej u toho těch 24/7 sedí aby nemusel drahej admin vartovat, a když někde něco zčervená, tak probudí příslušného admina, a mluvíte o zkušenostech z praxe?

24/7 NOC nema odhaduji 80% + firem. Zejmena SMB bude mit 1 admina nebo klasicky pripad je i podstav.

Zabbix tohle umí - lze vytáhnout počet zbývajících dnů do konce platnosti certifikátu a udělat trigger pokud klesne pod zadanou mez.

A ted si promyslete, jak se to bude chovat, kdyz zivostnost bude 45 dni. My mame u nasich 1 letych prvni uroven triggeru nastaveno na 1 mesic.

Tak ten trigger bude treba tyden predem. Porad spousta casu na to problem vyresit, pokud obmena neprobehne automaticky. Nebo nekdo potrebuje mesic na to, aby opravil rozbite obnovovani certifikatu? :-)

Tak na tuhle metodu jsem zvedav. Mame ve sprave projekty, kde nevlastnime domenu. DNS-01 metoda zde tedy pouzit nejde. HTTP-01 metoda zase nelze vyuzit na sluzby, co nemaji webserver.
No uvidime...kez by certifikaty zmizely ze sveta...

Pro použití DNS-01 přece nepotřebujete doménu vlastnit. Je možné validaci pomocí CNAME nebo NS záznamů přesměrovat jinam. Problém by byl jen v případě, kdy byste na té doméně potřebovali vystavovat certifikáty vy a ještě někdo jiný (majitel domény nebo jiný dodavatel).

Problém samozřejmě je, že kromě nevlastnictví domény tu je i neochota zákazníka něco udělat pro to, aby mu to fungovalo. Takže CNAME je vám k ničemu, když vám ho tam nemá kdo nastavit :))

Pak vám ale DNS-PERSIST-01 nijak nepomůže.

Tak jste si zaspekuloval a popojedem :-) Vase zkusenosti z praxe jsou nulove, jen teoretizujete, DNS-PERSIST-01 samozrejme pomoct muze (aneb "politicky" muze byt snazsi protlacit TXT zaznam nez ty jine alternativy)

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 ..

Já jsem pochopil článek tak, že to je přesně tohle, akorát bez toho mezikroku s emailem (LE ti řekne co tam máš přidat rovnou). Ale jak ten protokol přesně funguje, to nevím.

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.

ručně to nemusíte dělat ani pokud DNS služba neposkytuje API, protože existuje něco jako acme-dns

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.)

Ale kazda domena je viazana na nejaky email
Nemusí být. A i když je, ten e-mail typicky není veřejný.

oni mi poslu na email vlastnika domeny
Proto by tohle nefungovalo.

Tak je problem mat ucet na lets encrypt kde si mozem pridat domenu

Ak tým myslíš užívateľské účty, predpokladám že si chcú ušetriť cirkus okolo ich správy. Nepredpokladám, že si LetsEncrypt môže dovoliť "prehrabávať peniaze vidlami" na takéto aktivity.