Vlákno názorů k článku Let's Encrypt se osamostatní, přejde na svůj vlastní kořenový certifikát od Jan Havelka - Ja jsem asi nepochopil, co presne se tedy...

  • Článek je starý, nové názory již nelze přidávat.
  • 16. 4. 2019 9:57

    Jan Havelka

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

  • 16. 4. 2019 10:36

    Petr Krčmář

    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.

  • 16. 4. 2019 14:14

    Jan Havelka

    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.

  • 16. 4. 2019 16:31

    Ondřej Caletka
    Zlatý podporovatel

    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.

  • 16. 4. 2019 16:49

    Filip Jirsák
    Stříbrný podporovatel

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

  • 16. 4. 2019 23:29

    Jan Havelka

    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.

  • 17. 4. 2019 10:50

    Filip Jirsák
    Stříbrný podporovatel

    Ano, faktická změna je jenom v tom, který mezilehlý certifikát vám Let's Encrypt pošle při generování certifikátu by default. Oba mezilehlé certifikáty snad na HTTPS server dát nejde – seznam certifikátů, které server posílá, se podle mne chápe jako orientovaný graf od serverového certifikátu k důvěryhodnému certifikátu, tj. každý následující certifikát podepisuje ten předchozí.

    Vůči čemu se certifikát nakonec ověří také nemá server plně pod kontrolou – server může poslat mezilehlý certifikát podepsaný rootovským certifikátem Let's Encrypt, klient ale tomu rootovskému certifikátu nemusí důvěřovat. Za to ale klient důvěřuje IdentTrustu a odněkud má i ten mezilehlý certifikát Let's Encryptu podepsaný IdentTrustem. Klient podle položky Authority Key Identifier v zaslaném serverovém certifikátu zjistí, že může pro ověření použít ten mezilehlý certifikát podepsaný IdenTrustem a tomu důvěřuje, protože je podepsaný kořenovým certifikátem IdenTrustu. Nebo-li server poslal certifikační cestu k rootu Let's Encrypt, kterému klient nedůvěřuje, klient si ale našel jinou důvěryhodnou cestu k IdenTrustu a tím pádem důvěřuje i tomu koncovému serverovému certifikátu.