Vlákno názorů k článku Let's Encrypt se osamostatní, přejde na svůj vlastní kořenový certifikát od Ondřej Caletka - A není to nakonec celkem jedno, který mezilehlý...

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.