Názory k článku Let's Encrypt má šest nových certifikátů, přibude plná podpora ECDSA

Předpokládá se, že autorita na základě R3 začne vystavovat koncové certifikáty ke konci letošního roku. Na uživatele to nebude mít žádný dopad, jde o čistě formální změnu v řetězci důvěry.

To je poměrně optimistický předpoklad. V praxi bych spíš předpokládal, že se objeví tisíce rozbitých cest od podivných implementací ACME klientů, které řeší pouze koncový certifikát, protože mezilehlý je přece starost admina.

Takový klient je vlastně neúplný a je nebezpečné ho používat. Nedokáže reagovat na změny u autority a dřív nebo později správce narazí na to, že se mu rozbije automatická obnova. Přitom autorita samotná na to připravená je a patřičný mezilehlý samozřejmě klientovi poslat umí.

Všechny procesy, které LE zavádějí směřují k laicizaci operací. Je fakt, že laik (nebo poloprofesionál, abych hovořil kulantně) umí houby rozeznat dobrou, bezpečnou implementaci od špatné, neúplné a málo bezpečné.

Ano, přesně tak. Nezajímají mě detaily. Prostě potřebuji SSL certifikát pro svoje domény.

Když jsme u těch laických dotazů, když někdo používá certbot, dostane od určitého data automaticky ECDSA certifikát? :-)

Nedostanete. EC certifikát můžete mít už hóódně dlouho, jediné co se změnilo je to, že do teď byl ten certifikát podepsaný RSA. Nyní bude EC certifikát podepsaný pomocí EC. Nicméně, nic se nemění na straně Vašeho serveru.

Ještě dlužno poznamenat, že samotný EC certifikát se vidí málokdy. Obvykle se do serveru instalují certifikáty dva: EC a RSA. Kvůli kompatibilitě, ne každý klient si s EC poradí.

Takže pokud jste doposud EC neměl nakonfigurované, nezmění se na tom nic ani nyní.

Certbot (opravte mě někdo, jestli kecám) neumí automaticky získat jak RSA tak EC v jednom běhu. Musíte mít nainstalované dvě instance certbotu, dvě odlišné konfigurace. Jedna instance získává RSA certifikáty, druhá EC. Myslím, že se tím i rozbije konfigurační magie pro webservery (pluginy do certbotu).

Osobně certbot právě z toho důvodu nepoužívám, 90 % jeho "výhod" ztratíte, když chcete oba typy certifikátů. Používám dehydrated, který je jednodušší, ale dá se lépe zkrotit do této situace.

Mimochodem, krásně se v nahotě ukazuje, že lidé vůbec nechtějí řešit tyto otázky, ale že jsou víceméně nuceni tlakem okolností. Kdyby existovala opravdová poptávka, dávno by byly všechny tyto problémy vyřešené. Takto se 999 lidí z tisíce spokojí s výchozím nastavením certbota - tj. RSA 2048.

Je to kořenový certifikát, u těch je platnost 20 let běžná věc. Na rozdíl od RSA si nemůžete u EC algoritmů zvolit délku klíče aniž by doslo ke změně křivky, což může vyvolat problémy s kompatibilitou, takže použít stejný algoritmus jako podřízené certifikáty je jediné použitelné řešení.

Nicméně u kořenových certifikátů je konec platnosti v nich uvedený spíše jen horním odhadem jejich životnosti. To jestli vůbec a jak dlouho bude důvěryhodný je dané přítomností v příslušných trust storech a zcela běžně se děje, že je kořenový certifikát odstraněn dávno před koncem platnosti.

Prekopirovavam z mailinglistu postfixu,

Please note that the Let's Encrypt intermediate CA certificate "X3" will soon be
phased out in favour of "R3" and "E1" which have new keys, and so any DANE TLSA
"2 1 1" records matching "X3" will not match "R3" or "E1".

  https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html

If you are using Let's Encrypt with DANE-TA(2) [issuer CA] TLSA records, any extant
"2 1 1" records need to be augmented soon with additional records matching the new
"R3" and "E1", in advance of these reissuing your certificates.

Failure to act in time is likely to result in an outage once renewals switch to
signing via "R3" or "E1".

Links to the actual certificates can be found at:

        https://letsencrypt.org/certificates/
        https://letsencrypt.org/certs/lets-encrypt-r3.pem
        https://letsencrypt.org/certs/lets-encrypt-e1.pem

The "2 1 1" digests of "R3" and "E1" are (but don't take my word for it,
re-compute these for yourself):

        ; $ tlsagen lets-encrypt-r3.pem smtp.example.org 2 1 1
        ;
        _25._tcp.smtp.example.org. IN TLSA 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D

        ; $ tlsagen lets-encrypt-e1.pem smtp.example.org 2 1 1
        ;
        _25._tcp.smtp.example.org. IN TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10

The above were computed with the attached "tlsagen" script, but it is
prudent to also check with tools from other sources, this email message
could well have been a forgery (I hope your copy matches what I sent).

Na nektere uzivatele to muze mit dopad, tak at jste pripraveni :)

21. 9. 2020, 08:29 editováno autorem komentáře

Což je samozřejmě logické a jasné už ve chvíli, kdy si do TLSA dám klíč z mezilehlého certifikátu autority. Ten má omezenou platnost a autorita ho může kdykoliv vyměnit. Musím pak monitorovat, že se to nestalo a věci se mi nerozbily.

Pinovat mezilehlý klíč (nebo certifikát) má jen samé nevýhody: nechrání před vystavením podvrženého koncového certifikátu stejnou autoritou, klíč nemám pod kontrolou a musím (na rozdíl od self-sugned) posílat celou cestu. Mnohem jednodušší je pro TLSA v poště použít vlastní certifikát s vlastními pravidly.