Hlavní navigace

Vypršel kořenový certifikát DST Root CA používaný autoritou Let's Encrypt

Sdílet

anonymní 30. 9. 2021
Let's Encrypt logo Autor: Let's Encrypt

Jak už bylo certifikační autoritou Let's Encrypt předem avizováno, 30. září 2021 ve 14:00 UTC došlo k expiraci kořenového certifikátu DST Root CA, který byl používán jako dočasný po několik let. V zásadě by nemělo dojít k potížím, protože Let's Encrypt CA používá ISRG Root X1 pro RSA nebo ISRG Root X2 pro ECDSA již mnoho měsíců.

V případě neaktualizovaného ACME klienta je možné, že vygenerovaný full chain obsahuje expirovaný kořen a tedy selže ověření certifikátu. V tom případě je nutné provést upgrade klienta, například acme.sh, použít ACME API v02, zajistit, že bude preferovaný řetězec ISRG. Ve výsledku pak celý řetězec nechat přegenerovat.

Příklad konfiguračních změn pro acme.sh – v3.0.1
.acme.sh/account.conf:

DEFAULT_ACME_SERVER=‘https://acme-v02.api.letsencrypt.org/directory’

.acme.sh/example.com/example.com.conf:

Le_API='https://acme-v02.api.letsencrypt.org/directory'
Le_Preferred_Chain='__ACME_BASE64__START_SVNSRyBSb290IFgx__ACME_BASE64__END_'

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 1. 10. 2021 8:10

    Milan Keršláger

    ACMEv1 není funkční od července 2021, takže takové domény už mají expirovaný certifikát či právě expirovaly (a potřebují nový script tak jako tak).

    Psal jsem do diskuse k týden starému článku, že problém je u Microsoft IIS web serveru, který mezilehlé certifikáty vybírá sám a tvrdošíjně vybíral X3 až do jeho expirace (je nutný reboot).

  • 1. 10. 2021 8:32

    Milan Keršláger

    Pokud klient používá dostatečně nový software (openssl 1.1.0 a novější), problém není. Pokud má klient starý SW, je v Linuxu potřeba na serveru aktualizovat balíček ca-certificates na verzi 2021.2.50–72 (typicky skrze aktualizace, např. RHEL/CentOS 7) nebo přeložit openssl 1.0.2 s volbou X509_V_FLAG_T­RUSTED_FIRST (Ubuntu 16.04) případně udělat blacklist na DST Root CA X3 (případně ručně certifikát odebrat).

  • 1. 10. 2021 10:58

    bez přezdívky

    Mne se povedlo přes ACMEv1 získat certifikát ještě 25. září 2021 v Debian 9.13 a s acme.sh v 2.x Lets Encrypt to musel definitovně vypnout někdy mezi 25. a 30. 9.

  • 4. 10. 2021 15:45

    PajkD

    Bohužel bez zásahu do openssl buildu opravdu dlouhý LE chain s tím DST X3 cross-signem důvěrou "neprojde" ani po updatu ca-certificates. NSS based věcem zřejmě update certů i v rámci Centos 6 vault (6.10) stačí ...
    Protože mne to vadilo, vyrobil jsem si openssl-1.0.1e-58.pd1trfir.el6­.src.rpm (s trvale zapnutým -trusted_first). Zdá se, že funguje. V případě zájmu k nahlédnutí , technicky jde o patch

    - if (ctx->param->flags & X509_V_FLAG_T­RUSTED_FIRST)
    + if (/* Dufek - always - ctx->param->flags & */ X509_V_FLAG_T­RUSTED_FIRST)

    v openssl-1.0.1e/crypto/x509/x509­_vfy.c ...

  • 1. 10. 2021 10:25

    netwoR

    Někdy (např. na debianu 8) stačí zakomentovat starý CA certifikát v souboru /etc/ca-certificates.conf
    Updatovat CA certifikáty příkazem update-ca-certificates.

  • 1. 10. 2021 12:38

    SPM

    Na to že by neměl být problém od včerejška neřeším nic jiného... Curlu a všech věcech na něm postaveným validace selže, protože v ca-certificates najdou ten prošlý certifikát. Lhostejno, že server vrací správný fullchain a že v ca-certificates jsou ty ostatní certifikáty, všimne si to jako první toho prošlého a konec. Na debianu 10 update ca-certificates nepomohl, musel jsem z configu ten prošlý zakázat a přegenerovat.

    A abych se na tuhle zprávičku vůbec dostal, tak jsem zase musel tunit firemní fortigate. Byla na něm zaplá nějaká lehká SSL inspekce (nepodvrhává to klientům certifikáty, ale podívá se to napřed samo co tam je). Opět měl FG pocit, že certifikát je prošlý a klientovi tu session pak bloknul.

    Kamarádovi na turrisu omnii zase přestal fungovat DNS resolver, v logu taky nějaká certificate expired chyba...

  • 1. 10. 2021 15:32

    bez přezdívky

    To neni pravda. Ten certifikat se nachazi i v mnohem novejsich instalacich OS. Ta nefunkcnost pak zalezi na kombinaci verze openssl knihoven a podobne...

  • 1. 10. 2021 15:53

    ...

    tohle je podle mě přirozené, stejně jako používáš 7 let starou pračku (a nikdy jsi jí neaktulizoval), 10 let starou televizi (také jsi jí nikdy neaktualizoval), můžeš i takhle používat počítače, telefony a jiné věci.

    On ten systém aktualizací je pro spotřebitele strašně nevýhodný, běžně čekám, že produkt bude fungovat do jeho fyzického zničení či morálního zastarání. Tady najednou musím počítat s tím, že může kdykoliv "přestat fungovat" kvůli chybějícím aktualizacím (v případně např. některých Android telefonů dokonce ještě v zákonné záruce).

  • 1. 10. 2021 16:55

    byCx

    Ale telefon nepřestal fungovat. Jednoduše svět oddriftoval od jeho softwarové výbavy. Pokud používáte telefon z roku 2010, tak dřív nebo později na to narazíte i na dalších webech s certifikáty od jiných autorit. Nemluvě o tom, že ty weby už ani nemusíte správně zobrazit.

  • 1. 10. 2021 17:11

    ...

    proto jsem to dal do uvozovek. Z pohledu spotřebitele je vlastně jedno, kde je příčina, on to nedokáže nijak rozlišit.

  • 1. 10. 2021 17:32

    Jan Hrach

    > On ten systém aktualizací je pro spotřebitele strašně nevýhodný

    Pouze pokud si špatně zvolí, jaké produkty používá. Já mám třeba úplně všechna zařízení podporovaná nejnovějšími verzemi všeho až na:

    - notebook Acer, koupený v lednu 2008, na kterém jako poslední funguje Debian 10 (podpora do léta 2024) s kernelem 4.9 (podpora do léta 2022)

    - router TP-LINK TL-WR741ND z roku 2009 (nevím kdy byl koupený), na kterém jako poslední OpenWRT funguje 18.06 (podpora skončila někdy letos)

    > tohle je podle mě přirozené, stejně jako používáš 7 let starou pračku (a nikdy jsi jí neaktulizoval)

    Pračka (pokud to není nějaký cloudový nesmysl) neobsahuje komplikovaný software se vzdáleně zneužitelnými chybami.

    > 10 let starou televizi (také jsi jí nikdy neaktualizoval)

    Tohle není pro většinu uživatelů pravda, protože 10 let stará televize neumí přijímat současné české DVB-T2 s H.265.

  • 1. 10. 2021 20:00

    gilhad

    > 10 let starou televizi (také jsi jí nikdy neaktualizoval)

    >> Tohle není pro většinu uživatelů pravda, protože 10 let stará televize neumí přijímat současné české DVB-T2 s H.265.

    Zato dobře funguje s 20 let starým přehrávačem při přehrávání 30 let starých pásek :)

    Jo jo, taky pořád ještě občas hraju některé 40 let staré hry :)

  • 4. 10. 2021 12:17

    bez přezdívky

    > 10 let starou televizi (také jsi jí nikdy neaktualizoval)

    Tohle není pro většinu uživatelů pravda, protože 10 let stará televize neumí přijímat současné české DVB-T2 s H.265.

    To se dá řešit a taky se to často řeší zakoupením settopboxu :-).

  • 1. 10. 2021 13:14

    Radek Zajíc

    Pokud vám wget vrací "ERROR: The certificate of ‘(server name)’ is not trusted." nebo curl "curl: (60) SSL certificate problem: certificate has expired", posílá server v CA path i starý (expirovaný) root.

    Rychlý hotfix: starý (expirovaný) root zakažte v ca-certificates.conf:

    $ sed -i 's/mozilla\/DST_Root_CA_X3.crt/!mozilla\/DST_Root_CA_X3.crt/g' /etc/ca-certificates.conf
    $ update-ca-certificates
  • 1. 10. 2021 13:44

    tomas82

    Pro mne vše vyřešil ansible s playbookem:

    $ cat fix_le_certificate.yml
    - hosts: all
      handlers:
        - name: update-ca-certificates
          command: update-ca-certificates
      tasks:
       - replace:
           path: /etc/ca-certificates.conf
           regexp: '^mozilla/DST_Root_CA_X3.crt$'
           replace: '!mozilla/DST_Root_CA_X3.crt'
         notify: update-ca-certificates 
  • 1. 10. 2021 16:01

    bez přezdívky

    Web mi beží na aktualizovanom Ubuntu 16.04 LTS s OpenSSL 1.0.2g (deaktivoval som DST_Root_CA_X3.crt podľa nápovedy), pričom dnes (1.10.2021) som opakovane vystavil certifikát LetsEncript pomocou klienta využívajúceho ACME v2.

    Napriek tomu, že na Windows 10 mi vo všetkých prehliadačoch všetko funguje, sťažujú sa mi návštevníci/zá­kazníci, ktorí na web pristupujú z Windows 7 (Chrome/Opera/IE). Sám som si Windows 7 nainštaloval aby som to overil.

    Chcem sa opýtať či existuje nejaký návod, aby sa na moje stránky takýto návštevníci dostali (bez aktualizácie na Windows 10 či Ubuntu na 18.04). či už na strane môjho servera (Ubuntu 16.04) alebo na strane návštevníka/klienta (Windows 7)?

    Keďže to zatiaľ nevyriešili ani servery seznam.cz, heureka.cz, či root.cz, atď. predpokladám, že riešenie k dispozícií zatiaľ nie je.

    Na kombinácií Windows 7 a Firefox všetko funguje, asi z dôvodu, že Firefox využíva vlastnú aktualizovanú DB koreňových certifikátov a nie tú vo Windows 7.

  • 1. 10. 2021 17:53

    Dan Ohnesorg

    V pripade dehydrated se musi do configu pridat radek

    PREFERRED_CHA­IN="ISRG Root X1"

    a potom to generuje certifikaty neodkazujici se na ten expirovany koren ani v alternativni ceste.

    Treba www.root.cz uz posila takovy certifikat a koukal jsem, ze nepatchovany debian 7 na nej dokaze normalne pristoupit, kdezto na seznam se mu to nepodari.

  • 2. 10. 2021 0:10

    bez přezdívky

    Síce www.root.cz od 1.10.2021 už posiela certifikát bez odkazu na exspirovaný "DST Root CA X3", napriek tomu sa daný certifikát "ISRG Root X1" predvolene nenachádza vo Windows 7 a tak stránka nie je z daného systému dostupná (viď. https://ctrlv.sk/jVPe). Jedinou možnosťou je daný certifikát "ISRG Root X1" manuálne do systému importovať.

  • 2. 10. 2021 12:30

    Lol Phirae

    Včera skoro celý den víceméně nefunkční heureka.cz i na posledních W10, když se to už načetlo, tak to trvalo celou věčnost. Koukám, že ten certifikát radši převydali, aby se ten neplatný v cestě vůbec nenacházel.

    Platnost od: ‎pátek ‎1. ‎října ‎2021 16:56:15
  • 2. 10. 2021 13:23

    Dan Ohnesorg

    Taky to takle vesmes vsude resim, ono to totiz nema dobre reseni, jsou dve moznosti:

    Nechat tam expirovany koren v ceste - pak udajne dobre funguji weby pro stare androidy, kde se vyuziva chyby ve validaci - android duveruje nespravne expirovanym CA certifikatum, ktere ma "vypalene" v ROM. Ale nedostanou se tam lidi co maji v systemu novy X1 koren, ale maji stare openssl, ktere chce mit vsechny validacni cesty v poradku.

    Druha moznost, vygenerovat certifikat s cestou jen k novemu koreni. Tohle dobre chodi s tim starym openssl, ktere certifikat zvaliduje proti nove CA, ktera se vyskytuje vsude mozne. Ale odrizne to vsechny stare androidy. Zrejme to odrizne i lidi s windows 7, ale to je asi jedno, protoze windows 7 validuji certifikaty spravne a expirovane korenove CA neveri tak jako tak.

  • 1. 10. 2021 22:17

    Kaacz

    To je všechno sice hezké, ale ten ta současná doporučovaná CA "ISRG Root X1" je podepsána tou dead CA "DST Root CA X3" a Android 10 v mobilu to prostě zkontroluje a řve jako tur ... :)

    1. 10. 2021, 22:19 editováno autorem komentáře

  • 1. 10. 2021 22:25

    Petr Krčmář

    Pozor, certifikáty toho jména existují dva. Jeden je mezilehlý, je křížově podepsaný tím starým kořenem DST a existuje jen kvůli starým Androidům. Pak je tu klasický kořen, který je samostatný a je už několik let ve všech aktuálních systémech.

  • 3. 10. 2021 17:08

    Kaacz

    Jenže šumáci ze Seznamu dali na imap.seznam.cz certifikát, který vede finálně na ten vypršelý. L.O.L. R.I.P. :D


    imap.seznam.cz
    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
    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
    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

    A ten poslední issuer je ten "DST Root CA X3", který vypršel 30.9.2021 :(

    PS: nechápu, jak je možné, že LE R3 vydal certifikát s platností delší, než cokoliv v jeho chainu. Prostě LE = diletanti. :)

    3. 10. 2021, 17:11 editováno autorem komentáře

  • 3. 10. 2021 23:21

    Petr Krčmář

    Já vidím na 993 klasický řetězec, který začíná kořenem ISRG Root X1. Expirovaný DST Root CA X3 tam nehraje žádnou roli.

  • 5. 10. 2021 10:58

    Kaacz

    Ano, v chainu ten X3 nemají. Ale moje aplikace na emaily bere důvěryhodnost certifikátů vážně a ten podpis vypršelou X3 vidí a vadí to.

    Chápu, že ten můj problém s email aplikací je způsoben příliš přísnou bezpečnostní implementací ohledně důvěryhodnosti. Protože o tom hlavně certifikáty na serverech jsou. Ale protože LE má důvěryhodnost spíše zápornou, nechápu, proč vůbec ho některé servery používají ...

    A nechápu, že většina mladých IT, propagujících LE, mele furt o kryptování zdarma a nechápou, že certifikát serveru, který LE vydá prakticky komukoliv, má zápornou důvěryhodnost. A nechápou, že na mnohých serverech je ta důvěrhodnost důležitá. Na rozdíl od jejich osobních serverů na hraní. :)

  • 5. 10. 2021 11:40

    Kaacz

    V chainu nemusí být nutně root CA, stačí mezilehlé, aby se "dokráčelo" k tomu poslednímu root. Ten být v chainu nemusí a aplikace si ho najde buď ve storu nebo online, pokud má od podřízeného cert informace kam se obrátit. Já ho ve storu nemám, muselo si to tedy informaci o vypršení najít online.
    Takže v tomto případě, kdy poslední cert je podepsán sám sebou ale také vypršelou X3, mohou nastat dvě varianty dle přísnosti na bezpečnost. Benevolentnímu klientovi stačí ten poslední "také selfsigned X1". Či se u něj skončí, pokud ho má ve storu CA. Přísnější klient jde po X3, když ten poslední v chainu nemá ve storu.
    V mém Android 10 (čistý AndroidOne) v úložišti CA od LE nejsou. Google evidentně nevede LE mezi trusted CA. :)
    Ok, zkusím si v Androidu do CA přidat ten ISRG X1 ... :)

  • 5. 10. 2021 11:57

    Kaacz

    No ještě se to rozkrylo lépe...
    Pozor - ISRG Root X1 jsou dva zcela různé, je dobré ujasnit o který jde:
    - selfsigned - https://letsencrypt.org/certs/isrgrootx1.txt
    - crossssigned X3 - https://letsencrypt.org/certs/isrg-root-x1-cross-signed.txt

    A na imap.seznam použili ten cross-signed X3 ...

  • 5. 10. 2021 12:08

    Kaacz

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

  • 4. 10. 2021 8:56

    Filip Jirsák

    Je pozoruhodné, když o diletantech píše někdo, kdo si nedokáže přečíst ani vlastní výpis, který vkládá do diskuse. Vždyť tam tu platnost máte napsanou…

    Mimochodem, mezilehlé certifikáty běžně bývají podepsané více autoritami, takže to, že vy vidíte jeden řetězec, neznamená, že neexistuje i jiný, kde mohou být platnosti delší.

  • 5. 10. 2021 10:53

    Kaacz

    Je pozoruhodné, že někdo, kdo nedokáže pochopit psaný text, osočuje někoho z toho samého.
    Udaje posledního certifikátu (kromě platnosti), jasně ukazují, že je podepsán certifikátem root CA X3, jehož parametry včetně platnosti ve výpisu nejsou a o kterém již všichni víme, že vypršel. :)
    Lidé bděte a čtěte. Než začnete někoho osočovat... Pěkně jste si naběhl. :)

    Ke druhému odstavci:
    Ano, ISRG Root X1 je kromě X3 podepsán i jiným - sám sebou. Což je méně důvěryhodné než podpis jinou opravdovou autoritou.
    https://letsencrypt.org/certificates/

    PS: Chápu, že ten můj problém je způsoben příliš přísnou bezpečnostní implementací ohledně důvěryhodnosti. Protože o tom hlavně certifikáty na serverech jsou. Ale protože LE má důvěryhodnost spíše zápornou, nechápu, proč vůbec ho některé servery používají ...

  • 5. 10. 2021 12:13

    Kaacz

    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.

  • 5. 10. 2021 14:21

    Filip Jirsák

    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.

  • 5. 10. 2021 14:45

    Kaacz

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

  • 5. 10. 2021 14:54

    Kaacz

    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.

  • 5. 10. 2021 15:00

    Kaacz

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

  • 5. 10. 2021 16:57

    Filip Jirsák

    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.

  • 3. 10. 2021 11:16

    MichaelSt

    Já tomu teda moc nerozumím. Mailový klient TheBat! mi píše, že vypršel certifikát:
    FETCH - Root: "Digital Signature Trust Co.", "DST Root CA X3" Platný od 30.09.2000 21:12:19 do 30.09.2021 14:01:15. Platnost tohoto S/MIME certifikátu již vypršela!
    Nemám nejmenší tušení, co mám dělat. Z Wedosu, odkud se snažím poštu načítat, mi moc neporadili. Dle techniků se jedná o problém s LE certifikátem. Kdy toto Let's encrypt vyřeší přesně nevědí.
    Mohu si prý (dočasně) vypnout ověřování certifikátů, např. takto:
    stream_contex­t_set_option($con­text, 'ssl', 'verify_peer', false);
    Netuším, kam to napsat.

  • 4. 10. 2021 9:23

    Filip Jirsák

    Let's Encrypt to dál nijak řešit nebude, už to vyřešili přechodem na novou autoritu. Zaktualizujte si systém, máte tam pravděpodobně starý seznam důvěryhodných certifikátů a knihovnu, která špatně pracuje s tím, když je v seznamu expirovaný certifikát.

  • 9. 10. 2021 13:02

    MichaelSt

    Certifikát jsem do počítače nainstaloval, ten nový ISGRT.
    Ani po dlouhém testování mailového klienta TheBat jsem nenašel místo, kde se do něj dá nahrát nový certifikát. Návody z webu selhávaly.
    Ale našel jsem, jak ho přinutit, aby používal certifikát z počítače, a ne "ze sebe".