Názory k článku Let's Encrypt se osamostatní, přejde na svůj vlastní kořenový certifikát

A není to nakonec celkem jedno, který mezilehlý certifikát ACME klient dostane?

Stejně existuje na internetu netriviální množství stránek, které posílají jen koncový certifikát a spoléhají na prohlížeče, že se mezilehlý certifikát naučily při návštěvě jiného, správně nastaveného serveru. Tahle funkce dřív byla na desktopech a chyběla na mobilech, ale místo správného řešení – odstranění z desktopů – došlo k přidání obdobné funkce na mobilech, takže admini můžou nadále na správné nastavení serverů z vysoka kašlat.

Proto se domnívám, že i když můj počítač ISRG Root X1 znát nebude, úplně bude stačit navštívit libovolnou stránku, která bude posílat mezilehlý certifikát od IdenTrust a prohlížeče se cestu ke starému kořenu navždy naučí.

Kromě toho, když už budu chtít používat alternativní mezilehlý certifikát, jak takovou věc automatizovat? Let's Encrypt se může kdykoli rozhodnout začít vydávat místo z autority X4 namísto stávající X3, takže ruční nastavení mezilehlého certifikátu asi není úplně dobrý nápad.

spoléhají na prohlížeče, že se mezilehlý certifikát naučily při návštěvě jiného, správně nastaveného serveru
Opravdu se to prohlížeče učí? Myslel jsem, že používají jenom systémový seznam důvěryhodných autorit (případně profiltrovaný interním blacklistem). Ve Windows je spousta těch mezilehlých certifikátů v systémovém úložišti, myslel jsem si, že to je ten důvod, proč to funguje, když server pošle jen svůj certifikát. Nevím, jak je to u Firefoxu, ten nepoužívá systémové úložiště.

Některé autority mají těch alternativních řetězců víc, takže je běžné, že server sice posílá nějaký řetězec certifikátů, ale prohlížeč to nakonec stejně validuje pomocí úplně jiného řetězce.

Kromě toho, když už budu chtít používat alternativní mezilehlý certifikát, jak takovou věc automatizovat?
Podle standardu by měl ACME server poskytovat odkaz typu alternate na alternativní certifikační řetězce, viz:
https://tools.ietf.org/html/rfc8555#section-7.4.2 Ale stejně tam pak je: „Clients can fetch these alternates and use their own heuristics to decide which is optimal.“ Vlastně jde o to, který certifikát chci používat jako kořenový, což je poměrně jednoduchá heuristika.

Ale nezkoušel jsem, zda tuhle vlastnost ACME protokolu Let's Encrypt implementuje. V odchylkách Boulderu od ACME protokolu to vyjmenované není, ale známe Let's Encrypt…

Já nemám zkušenosti s Windows, ale na Linuxu rozhodně kešují mezilehlé certifikáty jak Chrome, tak i Firefox. Dlouhou dobu nekešovalo mobilní Chrome na Androidu, četl jsem tehdy mnoho diskuzí na téma „Certifikáty Let's encrypt nefungují v mobilech“. Ale někdy v roce 2017 přidali kešování i tam.

Mezilehlé certifikáty například neposílají některé CDN servery iVysílání. Závada se nikomu neprojeví, protože jde o certifikáty ze stejné autority, jakou používají vstupní brány dané CDNky, kterými musí každý prohlížeč projít. Když ale třeba z nástrojů pro vývojáře vykopírujete celou URL, ze které tečou data a pustíte na ní wget, zahlásí vám chybu TLS.

Ta možnost alternativního řetězu je fajn. Předpokládám, že certbot na to tedy bude mít nějaký přepínač, kterým si uživatel vyžádá alternativní řetěz a dál už se nemusí starat.

Nevíš náhodou z hlavy, jestli se ta cache certifikátů dá nějak zobrazit nebo i smazat? Nebo jestli jsou to nějaké soubory na disku v nějakém rozumném formátu?

Pod čarou – připadá mi, že to dobře ilustruje, jaký je „pořádek“ ve světě důvěryhodných certifikačních autorit. Že je pro autory prohlížečů jednodušší odchytávat mezilehlé certifikáty z provozu, než donutit certifikační autority, aby ty certifikáty poskytly přes nějaké API a prohlížeč je měl přibalené rovnou „z výroby“, jako má ty kořenové certifikáty.

U Firefoxu je to snadné, tam je v přehledu certifikátů autorit vždy jméno certifikátu a bezpečnostní zařízení – pro vestavěné kořenové certifkáty je bezpečnostním zařízením „Builtin Object Token“, pro naučené mezilehlé pak „Softwarové bezp. zařízení“.

Chtěl jsem kešování demonstrovat na stránce https://incomplete-chain.badssl.com/ otevřené v čistém profilu firefoxu, ale ukázalo se, že výchozí stránka, kterou Firefox otevře, používá certifikát ze stejné autority, takže se mi ho nepodařilo odnaučit. ;)

Chrome proti tomu ukazuje jen vestavěné kořenové certifikáty, o nakešovaných se asi z prohlížeče dozvědět nedá. V obou případech nejspíš půjde s keší certifikátů manipulovat pomocí nástrojů knihovny NSS (certutil) na databázový soubor někde uvnitř profilu.

Ja jsem asi nepochopil, co presne se tedy stane - vznikne novy (X5?) mezilehly certifikat, ktery uz nebude cross-signed ?

Jinak "delegace důvěry funguje na základě jmen (common name, CN)" je podle me nesmysl, to by tam nebyla duvera zadna...CA podepisuje certifikat svym privatnim klicem a ten podpis a tim i retez duvery se pak da overit jejim verejenym klicem...

Nevznikne nový mezilehlý, už teď existují dva. Jeden vystavil IdenTrust a druhý sám Let's Encrypt. Oba jsou dnes v prohlížečích důvěryhodné, takže by mělo být možné je libovolně zaměnit.

Samozřejmě že certifikáty obsahují i šifrovací klíče a to je jejich podstatou. Chtěl jsem tím jen vyjádřit, že výměna mezilehlého se stejným jménem je princip cross-signed. Za předpokladu, že je vše podepsané správnými klíči.

No ja jsem asi natvrdlej, ale na tom obrazku jsou oba existujici mezilehle cross-signed. Takze jakmile na server nainstaluju serverovy certifikat + kterykoliv z tech mezilehlych, tak to vzdy pujde overit proti obema korenovym CA.

Jeden certifikát může mít jen jednoho vydavatele, nikdy ne dva. Proto v tuto chvíli existují dva různé mezilehlé certifikáty (plus dva záložní), které mají stejný předmět, ale různé vydavatele. Oba jsou vystaveny na stránkách Let's Encrypt. Můžete je stáhnout a porovnat.

Certifikát se vždy podepisuje privátním klíčem. K němu příslušný veřejný klíč je pak součástí certifikátu autority. Let's Encrypt teď má jednu aktivní dvojici klíčů, privátním klíčem z té dvojice podepisuje koncové certifikáty (např. serverový certifikát pro root.cz). Vedle toho má ještě druhou, záložní dvojici klíčů, které teď nepoužívá. Veřejný klíč od toho aktivního privátního klíče je součástí mezilehlého certifikátu – a těch mezilehlých certifikátů vydaných pro tenhle jeden veřejný klíč může být víc. Což je aktuální stav Let's Encrypt – mají ten veřejný klíč (jehož privátním klíčem podepisují koncové certifikáty) jednak na certifikátu podepsaném od IdenTrust, a teď ten stejný klíč podepsali ještě privátním klíčem své kořenové certifikační autority. Tím vznikly dva různé certifikáty, podepsané dvěma různými klíči a certifikačními autoritami, obsahují ale ten stejný veřejný klíč. Koncové certifikáty pak můžete validovat přes oba dva ty mezilehlé certifikáty, protože při validaci certifikátu je rozhodující jenom klíč – ověřuje se elektronický podpis toho koncového certifikátu, nic jiného než veřejný klíč autority tedy není potřeba.

Na obrázku v článku tedy máte „Let's Encrypt Authiroty X3“, což představuje jeden veřejný klíč, ale k tomu veřejnému klíči existují dva různé certifikáty, každý podepsaný jinou kořenovou CA. Ten zakulacený obdélník na obrázku tedy nepředstavuje certifikát, ale spíš veřejný klíč.

Diky, uz jsem to pochopil. K cemu fakticky dojde je, ze ACME klient nove dostane v bundle by default ten ISRG mezilehly certifikat, nicmene pokud se nasadi s tim DST nebo (nebo obema), tak to stale bude mozne overit vuci DST.

Až mu vyprší platnost, tak rozhodně ano. Za dva roky už bude platit jen ten odvozený z ISRG.

Takové chování rozhodně není bezpečné. Let's Encrypt může kdykoli, bez předchozího upozornění, začít vydávat certifikáty ze záložní autority. Pokud takový certifikát dostanete a přilepíte k němu výše uvedený, bude sever posílat špatnou cestu.

Proto je lepší nechat si naservírovat správný mezilehlý certifikát ACME klientem. Pokud to ten váš neumí, opravte ho, nebo si pořiďte jiného.

Já bych to radši tak nechal. Ten kořenový certifikát ISRG Root X1 nebude rozšířen na starších Android mobilních telefonech, kde se na aktualizace systému kašle.

Například jsem zkoušel HUAWEI P8 Lite (stále se prodává) a ta testovací stránka od Lets Encrypt neprojde. Takže to vypadá, že budeme muset na serverech dávat certifikát podepsaný od DST Root CA X3. Tak, jak to máte v tom skriptu..