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