Názory k článku
Let's Encrypt ukončí v příštím roce podporu TLS certifikátů pro ověřování klientů

No to je docela opruz. Já jsem si na MTA serverech Postfix nastavil jak smtpd_tls_cer­t_file, tak smtp_tls_cert_file. Takže jestli tomu dobře rozumím, tak LE cert už nebudu moci použít v smtp_tls_cert_fi­le... Asi se to mohlo hodit i při nějakém jiném propojování mezi servery. Tak nějak se mi zdá, že se to moc ohýbá na použití browser - webserver.

omezení na pouze veřejné webové servery je jasné směrování, na vše ostatní je lepší použít nějakou alternativu. LE dělá jen problémy, když se provozuje na něčem jiném, on i ten transparency list je občas problém.

Já je používám na kdečem a problémy nedělaly nikde. Jako kvůli tomuhle nějaký Let's Encrypt fakt nepotřebuju. To "jasné směřování" obecně tak nějak postrádá smysl, ostatně stejně jako celé tohle vyšilování kolem certifikátů, absurdní zkracování platnosti a podobné zhovadilosti.

V té zprávičce ale stojí za pozornost hlavně to "Úprava je vyvolána změnami požadavků v Google Chrome...". Abychom tušili, odkud (už zase) vítr vane. Hnus.

Vždyť ty jsi pověstný tím, že ti vadí naprosto jakákoli změna a co není dvacet let staré, to nemáš rád. Já taky s léty lenivím a nechce se mi učit nové věci, ale tohle je fakt extrém.

Tohle je docela komentář mimo. Tady se nejedná o nějakou novou věc, vylepšení apod. Já osobně považoval LE za CA, která prostě vydává DV certifikáty for free a jsem jí za ně vděčný a nemůžu říct ani pumpička. Nepřispívám na ní, platí to sponzoři. Samozřejmě Google je spolu s Amazonem největší, takže se dá očekávat, že vývoj určují. Já si tu mohu tak akorát postesknout, no. Jedná se v podstatě o omezení služby. Certifikáty šly používat jako klientské a už nepůjdou.
Ad problémy s LE certifikáty v něčem. Pokud s nimi má něco problém, tak je to zřejmě problém toho bazmeku. Pokud není X509 rozšíření označeno jako critical, tak ho má software ignorovat. Pokud tak neučiní, tak je to chyba toho softu.

S někým si mě pletete. Vadí mi omezenost, samoúčelnost, neschopnost rozlišovat nutné a chtěné, přesvědčení, že technika vyřeší všechny problémy světa a představa, že v čem není technologie, není to free, cool a in a podobné zhovadilosti. To leda. Jakkoliv tohle vše je nejen tady až moc rozšířené. Technika by obecně neměla být určená k tomu, aby řešila problémy, které sama způsobila. Jinak je mi víceméně jedno pokud mi ji nikdo z výše uvedených důvodů nevnucuje.

Zcela nepřekvapivě mám ale úplně jiné priority než řešit, že se někdo rozhodl rozbíjet nějakou službu proto, že Google Chrome má požadavky. Fakt nevím, co vás na tom překvapuje.

A mimochodem, "učit se"... Neřeším tu nějaké učení. O tom tu blábolíte ledatak vy.

Jakou mám k Let's Encrypt alternativu potřebuji-li třeba deset certifikátů, nechci-li je mít u deseti providerů, složitě přehazovat konfigurace certbota anebo platit za to platit stovky euro? Povídejte, přehánějte. Celé je to jen dál pokračující privatizace a oligopolizace internetu a vůbec vám to zjevně nedochází. Pak ale přijde tady nějaký Jim a místo toho, aby se zamyslel nad tím, co se už dlouho celkem plíživě a systematicky děje začne vyprávět, jak se někdo, komu to vadí určitě jen "nechce učit". Svoje sebeprojekce si nechte pro sebe a řešte problém, který tady pomalu vzniká.

No a měl jste na druhé straně nějaký server, ke kterému byste se tím klientským certifikátem fakt přihlašoval? A četl jste dokumentaci, která od používání této volby dost důrazně odrazuje?

Nikde jsem neměl potřebu vynutit validaci klienta. Máte pravdu, že o nic v tomhle případě nepřijdu. V nastavení jsem to povolil a nikdy s tím problém nebyl. Popravdě si myslím, že dokud si o něj server neřekne, tak se klientský certifikát stejně nepoužije. Bylo ten jen takové nastavení co kdyby.
Jo, asi půjde všude to nastavení prostě zakomentovat...

V Office 365 se doporučuje "autentizovat" jiné poštovní servery organizace, aby byly důvěryhodnější pro detekci nevyžádané pošty.

Autentizovat lze pomocí IPv4 adres, ze kterých se posílá, nebo pomocí klientského certifikátu. Tj. při použití IPv6 je použití klientského certifikátu minimálně vhodné. Microsoft preferuje použití použití klientského certifikátu i pro IPv4.

Ano jsem nevěděl, že tam ten příznak dávají. Ale je škoda, že to ruší – získat zdarma důvěryhodný klientský certifikát není jednoduché.

Nicméně hlavní problém je v tom, že TLS vyžaduje klientské certifikáty, že nestačí veřejný klíč. Nenapadá mne žádná implementace, která by důvěřovala všem klientským certifikátům nějaké autority, a rozlišovala uživatele třeba podle e-mailu v certifikátu. Všechny implementace, co znám, vyžadují explicitní registraci konkrétního certifikátu – tudíž certifikační autorita je tam jen na obtíž, protože je to jen omezení, ale nic to nepřináší.

Cisco AnyConnect při přihlašování certifikátem ověřuje CA a poté validuje e-mailovou adresu vůči LDAPu/Radiusu.
Fortigate - přihlášení jako administrátor ověřuje CA a poté e-mailovou adresu.

Ale to jsme mimo Let's Encrypt a serverové certifikáty.

No, když to dělají zrovna tihle dva, je to pro mne pomalu doporučení dělat to jakkoli jinak… Nicméně předpokládám, že je to myšlené tak, že se bude používat interní autorita. Jak je ostatně napsáno i ve zprávičce.
Já jsem myslel spíš na to (ale nenapsal jsem to, uznávám), že by takhle někdo používal veřejné autority. Že by někdo povolil přihlášení certifikátem vydaným jakoukoli důvěryhodnou certifikační autoritou (třeba podle seznamu autorit Mozilly) a e-mail z certifikátu použil jako identifikátor uživatele. Nebo že by to samé udělal pro nějaký omezený seznam certifikačních autorit (protože do TLS výzvy serveru asi není reálné nacpat názvy všech důvěryhodných autorit).

Coze? Mr vsechno znam vsude sem byl nevi? Trebas strongswan. A predpokladam, ze vsechny pricetny vpnky. Ipsec vylozene pocita s tim, ze prihlasovani bude na tema klic+login.

Vidíte, a přitom by stačilo, kdybyste si nejprve přečetl ještě ty další dva komentáře ve vlákně.