Názory k článku
Vypršel kořenový certifikát DST Root CA používaný autoritou Let's Encrypt

Aha, v Android10 CA LE je, netušil jsem, že je pod organizací "Internet Security Research Group". Je tam ten "selfsigned ISRG Root X1". Přidal jsem ručně cross-signed X1 mezi CA a nepomohlo to, appka furt řeší vypršení issuera, který ani není ve trust-storu. :(

Oprava: ISRG Root X1 není (při)podepsán někým jiným.
prostě existují dvě verze ISRG Root X1 - selfsigned a cross-signed vypršelou X3.
Viz ten odkaz na LE certs.

Lidé bděte a čtěte. Než začnete někoho osočovat... Pěkně jste si naběhl. :)
Ne, já jsem si nenaběhl. To vy se tu pořád tváříte jako expert, ale neumíte přečíst ani výpis, který sám citujete; nevíte, jak se správně ověřují certifikáty; a jste strašně překvapen, že dva certifikáty mají stejné jméno (a to jste na to byl několikrát upozorněn).

Začnu od toho prostředního – ověřování certifikátů. Vaše poštovní aplikace neověřuje certifikáty přísněji, ověřuje je špatně. Ověřování certifikátů funguje tak, že máte seznam důvěryhodných certifikátů certifikačních autorit. Ten říká, že cokoli, co je podepsáno některým z uvedených certifikátů, je důvěryhodné. Dál to může být omezené dalšími vlastnostmi – účelem certifikátu, délkou certifikační cesty, teoreticky i pro koho je nějaký certifikát vydán (že by nějaká autorita byla důvěryhodná třeba jen pro určitou TLD), to ale ponechme stranou.

Jeden možný přístup, fakticky správnější, je ten, který používají starší verze Androidu – že jsou důvěryhodné všechny certifikáty v tom úložišti, bez ohledu na jejich platnost. (Podstatný pro ověření je ve skutečnosti jen veřejný klíč, který žádnou platnost nemá. Že jsou v tom úložišti celé certifikáty je jen zjednodušení.) Pokud konkrétnímu certifikátu nedůvěřujete, třeba protože mu skončila platnost, má se z úložiště vyndat.

Druhý přístup je zase technické zjednodušení – než hlídat platnost certifikátů a ve správné vteřině z úložiště expirovaný certifikát odebrat, necháme ho v úložišti a jenom na základě aktuálního času se budeme tvářit jako že tam není.

V obou případech to ale znamená, že mám nějakou sadu certifikátů považovaných za důvěryhodné (ve skutečnosti jsou to „kořeny důvěry“ a jde právě o ty veřejné klíče), a hledám, zda od nich existuje nějaká cesta k předloženému certifikátu. Nedůvěryhodný je takový certifikát, ke kterému se nepodaří najít žádná taková cesta. V úložišti důvěryhodných certifikátů neexistuje nic jako nedůvěryhodný certifikát.

Když se tedy na základě certifikátů v úložišti důvěryhodných certifikátů a certifikátů poskytnutých serverem vytvoří validační cesty, ověří se platnost těchto cest (platnost podpisů, časová platnost certifikátů poskytnutých serverem, další atributy jako délka cesty nebo účel certifikátu). Pokud z toho vyjde alespoň jedna cesta, která je plně validní, je považován za validní i koncový certifikát. Že tam jsou i nějaké jiné cesty, které se nepodařilo validovat, je úplně jedno. Pokud validační knihovna nechce důvěřovat expirovaným certifikátům uloženým v úložišti důvěryhodných certifikátů (protože volí ten druhý přístup nevyžadující tak častou aktualizaci úložiště důvěryhodných certifikátů), má expirované certifikáty z úložiště vyřadit hned na začátku a dál k nim vůbec nepřihlížet, jako by v úložišti vůbec nebyly. Pokud to tak nedělá, není to přísnější validace, je to špatná validace.

No a teď k tomu vašemu výpisu, kterému nerozumíte.

Subject: CN = imap.seznam.cz
Issuer: C = US, O = Let's Encryt, CN = R3
Validity
Not Before: Aug 2 14:01:57 2021 GMT
Not After : Oct 31 14:01:55 2021 GMT

Tohle (nahoře) je koncový certifikát vydaný pro imap.seznam.cz, klasický certifikát vydaný LE na 3 měsíce.

Subject: C = US, O = Let's Encrypt, CN = R3
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Validity
Not Before: Sep 4 00:00:00 2020 GMT
Not After : Sep 15 16:00:00 2025 GMT

Tohle je mezilehlý certifikát LE, s platností na 5 let. Opět klasické řešení třístupňové hierarchie: kořenový certifikát – vydávající certifikát – koncový (serverový) certifikát, tohle je ten prostřední, který uvolňuje ruce certifikační autoritě.

Vydávající certifikát je:

Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Validity
Not Before: 4.6.2015 13:04:38 CEST
Not After : 4.6.2035 13:04:38 CEST

To je opět klasický kořenový certifikát certifikační autority, self-signed certifikát s platností do 4. června 2035, má čtyřkilový RSA klíč, SHA-256 otisk certifikátu je 96:BC:EC:06:2­6:49:76:F3:74:60:77:9A:C­F:28:C5:A7:CF:E8:A3:C0:A­A:E1:1A:8F:FC:E­E:05:C0:BD:DF:08:C6. Tenhle certifikát byste měl mít uložen v úložišti důvěryhodných certifikátů a od něj vede platná certifikační cesta k tomu koncovému certifikátu Seznamu, který je tím pádem považován za důvěryhodný.

Pak vám server poslal ještě jeden certifikát navíc:

Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3
Validity
Not Before: Jan 20 19:14:03 2021 GMT
Not After : Sep 30 18:14:03 2024 GMT

Pro vás je zbytečný, protože v aktuálním systému máte ten důvěryhodný certifikát uvedený výše a k němu se najde validační cesta. Tohle je ale trošku speciální certifikát, je křížově podepsaný jinou certifikační autoritou (což je v pořádku, i takových certifikátů je spousta). Všimněte si, že má stejné jméno a má stejný veřejný klíč – což je právě ten trik, kterým se docílí toho, že k jednomu koncovému certifikátu vede více certifikačních cest. No a tenhle certifikát právě propojí celou autoritu LE na důvěryhodný certifikát od IdenTrust. Tomu už sice skončila platnost, takže validační knihovny ho neberou v úvahu – ovšem starší verze Androidu platnost důvěryhodných certifikátů v úložišti neřeší, takže považují za validní i cesty vedoucí k tomuto certifikátu. Proto bude i na starém Androidu tato certifikační cesta vyhodnocena jako validní. Což je náhrada za to, že tyto verze Androidu neznají ten kořenový certifikát ISRG Root X1, takže nebýt tohohle triku, nedokázaly by ověřit mezilehlý certifikát LE R3 a tím pádem ani koncový certifikát.

Jediná věc, kterou je tenhle křížově podepsaný certifikát opravdu výjimečný, je to, že má platnost až do roku 2024, jak je vidět i z vašeho výpisu, nebo-li má delší platnost, než je platnost vydávajícího certifikátu. Díky tomuhle triku bylo možné prodloužit životnost certifikátů LE na starých Androidech, které ještě neměly (a nikdy mít nebudou, protože nedostávají aktualizace) kořenový certifikát LE. To, že má certifikát delší platnost než vydávající certifikát je sice „divné“, ale validaci to nijak nebrání – platnost certifikátu je atribut podepsaný certifikační autoritou, je to tedy jedna z věcí, které důvěřujete, pokud certifikát certifikační autority zařadíte (v praxi spíš ponecháte) mezi důvěryhodné.

Tady k té hierarchii máte i obrázek, modrá cesta je ta, která se použije u aktuálních systémů, které znají kořenový certifikát LE, zelená cesta se použije na starých Androidech. V obrázku je jedna nepřesnost – ty dva koncové (bílé) certifikáty vpravo by ve skutečnosti měly být jenom jeden – „oba dva“ jsou podepsané stejným klíčem a mají stejný název vydávající autority, jsou tedy identické, je to jeden a ten samý certifikát. Ten vlevo je opravdu jiný, protože byl vydán certifikátem s jiným názvem (LE X3, v obrázku je to špatně) a hlavně jiným klíčem – X3 měl dvoukilový RSA klíč, nový X1 je čtyřkilový RSA.

Budu reagovat jen na jedno a trvám na tom, že neumíte číst a osočujete zbytečně.

V mém výpisu je chain poskytovaný imap.seznam.
V tom chainu je zcela jasné, že se to odkazuje na CA ISRG Root X1 podepsaný cross pomocí propadlého X3:
Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3
Validity
Not Before: Jan 20 19:14:03 2021 GMT
Not After : Sep 30 18:14:03 2024 GMT

Takže mi prosím nepodsouvejte váš selfsigned ISRG Root X1 viz váš příspěvek:
Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Validity
Not Before: 4.6.2015 13:04:38 CEST
Not After : 4.6.2035 13:04:38 CEST

Tyto dva certifikáty mají sice shodné CN, ale jinak jsou to zcela různé certifikáty. A pokud si myslíte, že jeden cert může zastupovat druhý (pokud mají stejné CN), tak asi víte o certifikátech prachmálo vy ...
HOWGH ... :)

Jo nejvíc mě rozsekalo vaše tvrzení:
Jeden možný přístup, fakticky správnější, je ten, který používají starší verze Androidu – že jsou důvěryhodné všechny certifikáty v tom úložišti, bez ohledu na jejich platnost.

Toto vaše tvrzení platí pouze pro použití certifikátu jako podpisu dokumentu, který byl prokazatelně podepsán v době platnosti certifikátu.

Mimochodem pane chytrej, co ví jak fungujou certifikáty:
víte něco o tom, že kromě časové platnosti certifikátu existují i revokace certifikátů (i když jsou v čase platné) a správně by se měla i ta revokace kontrolovat?
U serverů se to bere jinak a pro účely zneplatnit např. zdiskreditovaný certifikát, existují ty revokace.

L.O.L. Takže ty certifikáty vlastně máme jen kvůli tomu šifrování provozu, důvěryhodnost serveru je nepodstatná?
Tak si s těmi certifikáty třeba vytírejte, když jsou vám fuk ...
Nemá diskutovat s někým, kdo je mimo v základech, k čemu jsou certifikáty serverů ... sbohem.

No přečetl jsem si ještě jednou ten váš obsáhlý výpis .. přestal jsem před částí s mým X1 cross X3 :)
Problém je ten, že v tom chainu ze serveru je uveden i ten cross cert a nevím proč, ale Android10 (či ta emailová appka na něm) ignorují ten selfsigned X1, který v úložišti CA má. Prostě jde po tom X3 ... :(

Proč pořád píšete o něčem, čemu nerozumíte?

Tyto dva certifikáty mají sice shodné CN, ale jinak jsou to zcela různé certifikáty.
Pro vaši informaci, jak fungují certifikáty: certifikát je soubor nějakých údajů elektronicky podepsaný certifikační autoritou. Konkrétně třeba certifikát serveru (vystavený na doménové jméno) říká: Vlastník privátního klíče příslušného veřejnému klíči v tomto certifikátu je držitelem domény uvedené v tomto certifikátu. To celé podepíše autorita svým privátním klíčem.

Vy pak někde musíte mít veřejný klíč té autority, které důvěřujete – díky jejímu veřejnému klíči ověříte podpis na certifikátu, takže můžete věřit, že ten certifikát vystavila příslušná certifikační autorita. Nebo-li pro ověření platnosti certifikátu potřebujete veřejný klíč certifikační autority, nic jiného.

Jenže těch certifikátů důvěryhodných autorit máte běžně desítky. Kdybyste tam měl jenom veřejné klíče, musel byste zkusit podpis na předloženém certifikátu ověřit pomocí každého veřejného klíče v seznamu a zkoušet, zda některý veřejný klíč bude pasovat. To by nebylo zrovna efektivní ani rychlé.

I proto jsou v úložišti certifikátů uložené celé certifikáty, ne jen veřejné klíče. A certifikát certifikační autority v sobě povinně má rozšířený atribut „Subject Key Identifier“, který jednoznačně identifikuje veřejný klíč certifikátu. Obvykle se přímo z veřejného klíče odvozuje, ale není to nutné. Všechny certifikáty podepsané tímto privátním klíčem pak v sobě mají hodnotu ze „Subject Key Identifier“ zopakovanou, konkrétně v rozšířeném atributu „Authority Key Identifier“.

Takže vy pak dostanete třeba serverový certifikát k ověření, z něj si vyčtete „Authority Key Identifier“ a hledáte v úložišti důvěryhodných certifikátů všechny certifikáty, které mají „Subject Key Identifier“ stejný, jako „Authority Key Identifier“. (Obdobně se postupuje i s dalšími certifikáty, které poslal server.) Tím získáte jeden nebo několik málo kandidátů, které mohou obsahovat veřejný klíč, který odpovídá privátnímu klíči, kterým byl podepsán daný certifikát. (Správně by všechny ty klíče měly být stejné – nenapadá mne důvod, proč by byl vydán stejný „Subject Key Identifier“ pro různé klíčové dvojice, považovla bych to za prasárnu.) No a těmi několika málo podpisy ověříte ten předložený certifikát – resp. obvykle bude stačit ověřit jeden a dostanete validní certifikační cestu, takže další už není potřeba zkoušet.

Konečně se dostáváme k tomu, co vám uniklo – pro jeden veřejný klíč a „Subject Key Identifier“ může být vydáno několik různých certifikátů. To je právě případ těch křížově podepsaných certifikátů – vydáte certifikát s veřejným klíčem a „Subject Key Identifier“ jako self-signed kořenový certifikát. A zároveň si necháte ten samý veřejný klíč a ten samý „Subject Key Identifier“ dát na jiný certifikát, který podepíše jiná certifikační autorita. Když na to přijde, může vám ještě jiná certifikační autorita vydat třetí certifikát ke stejnému klíči.

Mimochodem, tohle vytváření více certifikátů s jedním klíčem používají certifikační autority běžně, vytvářejí tak své mezilehlé (vydávající) certifikáty. Vydávají koncové certifikáty podepsané svým privátním klíčem, k tomu existují dva různé mezilehlé certifikáty se stejným klíčem, a ty dva různé mezilehlé certifikáty jsou podepsané starým a novým kořenovým certifikátem kořenové autority. To umožňuje autoritě plynule přejít na nový kořenový certifikát, protože ten koncový certifikát lze správně validovat dvěma cestami, jednou ke starému kořenovému certifikátu, druhou k novému. Někdy jsou ty certifikační cesty ještě spletitější. LE použil skoro ten samý princip, akorát ten starý kořenový certifikát nebyl jeho, ale jiné autority.

Takže ty podle vás „naprosto různé“ certifikáty mají ve skutečnosti stejný veřejný klíč, takže zas až tak naprosto různé nejsou. No a celé se to dělá proto, že koncový certifikát podepsaný tím společným privátním klíčem obou certifikátů validují oba dva tyto certifikáty. Nebo-li stačí, aby klient důvěřoval alespoň jednomu z těch dvou certifikátů a bude důvěřovat i koncovému certifikátu.

Jestli do toho nějak vstupuje jméno uvedené v certifikátu certifikační autority (které je zopakované jako vydavatel ve vydaném certifikátu), resp. co by se stalo, kdyby se tato jména neshodovala, to nevím. Ale nikdy jsem takovou variantu certifikátů neviděl – i kdyby to fungovalo, bylo by to pro lidi matoucí.

Ověřit si to můžete sám, stáhněte si oba dva certifikáty „ISRG Root X1“ a porovnejte si jejich veřejné klíče – oba dva certifikáty mají čtyřkilový RSA klíč v hexadecimálním zápisu začínající 30820222300D. Bingo!

Toto vaše tvrzení platí pouze pro použití certifikátu jako podpisu dokumentu, který byl prokazatelně podepsán v době platnosti certifikátu.
Ne, toto moje tvrzení platí obecně. V „trust anchors“ je prostě seznam veřejných klíčů, kterým důvěřuju. Pokud nějakému nedůvěřuju, do toho seznamu nepatří, chybí tam to „trust“.

Mimochodem pane chytrej, co ví jak fungujou certifikáty:
víte něco o tom, že kromě časové platnosti certifikátu existují i revokace certifikátů (i když jsou v čase platné) a správně by se měla i ta revokace kontrolovat?
U serverů se to bere jinak a pro účely zneplatnit např. zdiskreditovaný certifikát, existují ty revokace.
Vím to a s tématem to nijak nesouvisí. A nebere se to jinak u serverů nebo u dokumentů, v obou případech nemáte revokovanému certifikátu důvěřovat. Rozdíl je v tom, že u podpisu dokumentu si můžete počkat a revokaci kontrolovat později (po vydání dalšího CRL), u serveru je potřeba to kontrolovat hned při navazování spojení. Proto se v ideálním případě používá OCSP stapling, tj. server rovnou při navazování TLS spojení přidá OCSP odpověď certifikační autority, že daný certifikát nebyl revokován.

L.O.L. Takže ty certifikáty vlastně máme jen kvůli tomu šifrování provozu, důvěryhodnost serveru je nepodstatná?
Jak jste na takový nesmysl přišel? Právě naopak, certifikáty vůbec nesouvisí s šifrováním provozu. Mimochodem, neslouží ani k „důvěryhodnosti serveru“. Slouží pouze pro ověření identity serveru, případně klienta.

Problém je ten, že v tom chainu ze serveru je uveden i ten cross cert
Při správné validaci to není problém. Naopak bez toho by nefungovalo ověření toho serverového certifikátu na starých Androidech.

nevím proč, ale Android10 (či ta emailová appka na něm) ignorují ten selfsigned X1, který v úložišti CA má. Prostě jde po tom X3 ... :(
To je chybná implementace ověřování certifikátů. Pravděpodobně je tam staré openssl. Pomohlo by ten starý X3 certifikát z úložiště důvěryhodných certifikátů odstranit. Když máte v úložišti i ten nový X1, bude se LE ověřovat vůči němu a starý X3 k ničemu nepotřebujete.