Názory k článku
Apple podal návrh na postupné zkracování platnosti certifikátů pro HTTPS

Škoda že není větší tlak na plošné zavedení DNSSEC + DANE. Spousta webů by žádné certifikáty nepotřebovala.

Dnssec rozbiji provoz, jestli chces priklad, tak s tim nefunguje IPv6 only sit, ktera by chtela komunikovat do Ipv4 site. Protoze tam musi DNS vracet IPv4 prelozenou do IPv6 prostoru.

Dane prozmenu brani smirovani, browser se pak nebude ptat nejakyho seznamu certifikatu jestli zrovna tenhle zna.

A mimochodem https://bugzilla.mozilla.org/show_bug.cgi?id=14328

25let. To souvisi s tim DANE.

Dnssec rozbiji provoz, jestli chces priklad, tak s tim nefunguje IPv6 only sit, ktera by chtela komunikovat do Ipv4 site. Protoze tam musi DNS vracet IPv4 prelozenou do IPv6 prostoru.

To není fundamentální problém, řeší ho např. RFC7050. Kdyby byla vůle, tak technické problémy jsou řešitelné.

Skutečný důvod je, že by se tím decentralizovala moc, a to korporátní ilumináti nechtějí.

To je hodne izolovany case, koncove resolvery (na klientech) moc nevaliduji tak jako tak. A validaci na mezilehlem resolveru (toho, ktereho se ti klienti ptaji) jde vyresit i s DNS64. Mimoto, je tu i dalsi mozna cesta skrze IPv6 mostly, t.c. ve fazi draftu. Aneb cesticky tu jsou, kdyz se chce.

A certifikační autority nebudou mít co žrát...

Na hračkoidní weby by TLSA stačil, ale browsery to nepodporují.

Protoze DANE zabiji CAcka a ty se tomu velmi, velmi brani. Vzdyt by si pak kterejkoliv admin mohl vystavit certifikat na 100 let, rict "tomuhle certifikatu verim" a CAcka by prisly o penizky. To nikdy nesmi projit.

V dobe, kdy tu existuje vicero poskytovatelu vydavajici certifikaty bezplatne tento argument s penizky taky uz jaksi pada...

To jako budu měnit hvězdičkové certifikáty u zákazníků 8x za rok? To nebudu dělat nic jiného ....

no holt se to bude muset automatizovat...

Sem zvedav, jak budes automatizovat miliardy krabek. Na stari nezalezi, protoze to neumi zadna. A to ani takove, za ktere se plati 100k+.

Proxy? Nerikam ze to je prijemne, ale tvrdit ze to nejde je nesmysl....

A kde se dá ten japonec SETO najmout?
Na různých FW typu SOPHOS, FORTIGATE to jde dost těžko ...

15. 10. 2024, 12:59 editováno autorem komentáře

Tak je asi čas, začít tam dávat něco rozumnějšího.

A to je co ?

tak u Fortigate už cert měníme přes api, co je s tím za problém? Sophos to bude mít nejspíš podobně.

Díky automatizaci certifikátů se u klientů prakticky přestali povalovat certifikáty v chatech, emailech, na discích a všichni ví, kde přesně jsou. Zároveň se tahle část začala také automatizovat a testovat, tj. dnes už víme jaké správné nastavení je pro FW a ne, že k tomu nemá nikdo ani čárku a prostě to je nějak 5 let nastavené a nešahá se do toho.

Myslím, že ta kultura se výrazně zlepšila, jako vedlejší efekt krátkých certifikátů je to super.

Každopádně tohle zkracování přidělává neřešitelné problémy pro různé krabičky, které nejsou v servovně ale u zákazníků, u nich žádné dobré řešení není a vše se musí připojovat na internet a dělá proxy přes vlastní servery, což zrovna není dobré.

No, nebo se vykašlat na REST/web a prostě použít šifrovaný binární protokol.

Díky za tip, API zatím neřeším, bo nemám důvěru, jestli se něco jiného nerozbije.
Nevím jak u FG, ten jsem jen plácl, ale u Sophosu musím cert. nahrát a pak povyměňovat všude ručně.
Nejde v objektu certifikátu nahradit obsah aby se následně objekt změnil všude v konfiguraci, kde je použit.

Forti jako vazne? ACMe nam to normalne dela? Co se treba dovzdelat nez zacnu hejtit?

Pokud myslite to co je v GUI, tak to vam umozni let's encrypt certifikaty pro vlastni zarizeni. Pokud treba pouzivate deep inspekci, tak tam musite menit certifikat rucne nebo se pletu?

No pokud do toho takhle šlápnou velcí hráči typu google a Džabko, tak lze od renomovaných dodavatelů ocekavat nové FW s podporou ACME...
Např. FORTIGATE umí acme od verze 7.0

Ne vzdy je to jednoduse mozne. Tim spis pokud mate jako korporat mate deal s CA a je hodne tezke z toho vycouvat. Hezky si vas omotaji kolem prstu privatnim api na vydavani certifikatu. A k tomu parta opicaku ktera se za to plati.
Nedokazu si predstavit kolik malych appek to bude muset resit.
Je sice mozne ze timto rozhodnutim se vytvori tlak na vydavatele certifikatu aby zavedli univerzalni mechanismy, nicmene to nejakou dobu trva.

Jenze vydavatele certifikatu jsou ve skutecnosti to nejmensi. Tech tzv "duveryhodnych" je par. Problem je, jak budes ty certifikaty dostavat tam, kam je dostat potrebujes. Uz to, ze si ten cert vygenerujes jinde je vlastne fail. A do naprosto drtivy vetsiny veci ho proste nedostanes jinak, nez rucne.

A i kdyz nacpes, je s tim dalsi krasna vec ... ve vetsine pripadu pak musis tu vec celou restartovat. Kdyz to je 1x rocne, da se to zkousnout, 4x rocne uz je na hrane, ale castejs ...

Tyto mechanismy mame vicemene zmaknute. Vicemene protoze vzdy prijde nejaky hloupy startup kde cekam nejakou nestandartni "inovativni" zradu. Pro nas nejvetsi koule na noze jsou ty CA. Uz tu nekdo popisoval korporatni kolecko trvajici mesic. U externich sajt je toto take nas pripad. Uplne stejne blby proces.
Balancery, firewally obvykle problem nejsou pokud vendorovi nerupne v kouli - mluvim o tobe Palo Alto a tvych QA.
Pritom interni systemy maji proces automatizovany nebo alespon poloautomatizovany.

16. 10. 2024, 07:10 editováno autorem komentáře

No... U nás platí pravidlo, že tyhle placené certifikáty prostě nesmí obnovovat automat, dokonce ani řadový pracovník. Je potřeba nejprve projít kolečkem v interním systému, kde odpovědná pověřená osoba popíše, na co a proč potřebuje utratit těch pár dolarů za certifikát, pak to musí schválit manager, potom teprve lze podat žádost. Vygenerovaný certifikát je pak předán na systém (často u dodavatele) k nasazení, které se děje výhradně ve stanovených termínech (1× týdně). Certifikát musí být obnovený nejméně 10 dní před vypršením platnosti, a to nejprve v testovacím prostředí a nejméně za týden ve dvou vlnách v produkčním prostředí.
Celkem tedy cca tři týdny pilné práce, kterou musíte ukončit 10 dní před koncem platnosti - to znamená, že při platnosti 45 dní máte poté 24 dní pauzu, než s tím začnete znova.

Nevím, zda bude rychlejší změna délky platnosti, nebo změna interních korporátních předpisů... ;oD

Chybne nastaveny korporatni proces neni problem technologie :-) A ono tvrdy naraz do zdi donuti i korporat ty veci vyresit pricetneji.

To, že zadřete pár ajťáků neustálým obnovováním certifikátu rozhodně není tvrdý náraz do zdi!
Prostě se řekne, že je to jejich povinnost, a když to zvládali dosud, budou to zvládat i nadále - a ne-li, pocítí to na finančním ohodnocení. Rozhodně nepředpokládám, že kdokoliv svolí s automatem, generujícím opakovaně nové a nové platby - jak jde o peníze, jsou managoři zcela nesmlouvaní!

Pokud jsem to pochopil správně, tak v plánu bylo také ukončit vydávání hvězdičkových certifikátů. Ale možná už od toho upustili.

To bude nejspíš 12x za rok, když už teď se krátký certifikát obnovuje ve 2/3 platnosti.
30 dnů na provoz a 15 dnů rezerva na ruční zásah, když ACME selže.

Někdo chce mít hodně aktuální seznam živých webů.

Někdo chce mít hodně aktuální seznam živých webů.
Přemýšlel jste nejdřív, než jste tohle napsal? Kdo je podle vás ten „někdo“? K čemu by mu ten seznam byl? Nemá náhodou daleko lepší prostředky, jak by takový seznam získal? Takové, které neselžou ani u hvězdičkových certifikátů? A opravdu má ten někdo takovou moc, aby zmanipuloval celé CA/B fórum?

Narozdil od tebe zjevne vi, ze spouta nejen webu kterej pouzivaji certifikaty neni verejne dostupna. A jejich seznam se zcela jiste da vyuzit i prodat.

Škoda, že já jsem nepsal nic o veřejných webech. Každopádně kdyby chtěl Apple vytvářet seznam živých webů, má k tomu jako autor několika operačních systémů a prohlížeče mnohem lepší možnosti, než CT – který je navíc veřejný, takže ten seznam může využít a prodat úplně kdokoli. Takže z té vaší konspirace proti Applu (nebo možná proti Googlu, v diskusi se ukázalo, že konspirátoři mají problém přečíst si aspoň nadpis zprávičky) vyplývá, že by se Apple (nebo Google) vlastně zbavovaly své konkurenční výhody.

Mimochodem seznam webů, které nejsou veřejně dostupné, musí být opravdové terno – nevíte čí ten web je, co na něm je, jenom víte, že někde v internetu to doménové jméno někdo používá. Když budete mít štěstí, podaří se vám ho přeložit. Po takovém seznamu fakt všichni touží, a nejvíc touží po tom, někomu za něj zaplatit, i když si ho mohou stáhnout zadarmo.

Hvězdičkové certifikáty už prostě nebudou.

Proč si vymýšlíte?

Moc nechápu smysl toho zkracování....
Rozumím, že spolehlivě nefunguje propagace revokovaných certifikátů do prohlížečů...
Ale - životnost napadených a škodících webů se už teď pohybuje v rámci hodin, tak pokud bude platnost certifikátu i jen desítky dnů, tak stejně takový web bude moci škodit desítky dnů a reálně se nic nezlepší.. Nebo mi něco uniká?

Za mě to celé visí na třech pilířích.

A) za certifikátem jsou i nějaké kryptografické algoritmy, které se ale mohou stát velice rychle zranitelné a rychlá výměna certifikátů zmanená i možnost rychle vylepštovat kryptografické algoritmy. Pamatuji doby s md5, kdy byly platné certifikáty i v době, kdy už nebylo rozhodně správně je provozovat.

B) v rámci certificate transparency se evidují všechny vydané certifikáty, snížením platnosti se sníží i náklady na provoz jejich seznamů, to dost výrazně.

C) zlepšení certificate managementu, aby byl plně automatizovaný a dostatečně robustní, protože jeden napadený server ovlivňuje celé své okolí a hlavně uživatele.

Ač se Google rozhodl sám, tak se o tomhle mluví ve více kruzích. Za mě to je mezikrok jak celý proces udělat ještě více odolné.

Pořád tady platí se tohle omezení na 90 dní se týká pouze certifikátů, které jsou určeny pro veřejný internet a společný prostor, interní či vnitřní certifikáty pořád můžeš mít jakékoliv. Chápu to tak, že ve veřejném prostoru zase nemám takovou volnost si vše dělat podle sebe a musím se přizpůsobit většině.

ad B = není CT založen na Merkel tree a append-only logu, takže úspora se tam nemá jak projevit?

ano, CT je merkle tree, ale v něm jsou pouze hashe (a pár dalších údajů), log je distribuovaný, což znamená, že se vytváří pravidelně nové a nové stromy a podepisují se navzájem.

Mít data uložená je levné, mít ke k dispozici milionům požadavků za hodin je už o něčem jiném. Nic neroste věčně a o tom kolik dat můžeme mít v CTL se mluví, i nové CT 2.0 už počítá s uzamknutím CTL a vytvořením nového.

ad B) to by me zajimalo, japa chces realizovat usporu, kdyz mas rekneme milion certifikatu platnych rok, vs milion certifikatu platnych mesic. Jen budes mit 12x vetsi provoz pri jejich aktualizacich.

"interní či vnitřní certifikáty pořád můžeš mít jakékoliv"
To chci videt, jak budes chromaka nebo jabko presvedcovat o tom, ze ten tvuj 10 let platnej certifikat ma akceptovat ... jo aha, ono to nejde, jak bys vedel, kdybys to zkusil.

Ja to narozdil od tebe vim, protoze par jabkem postizenych kusu ve sve bubline mam. Jednoho krasneho dne vsichni dorazili, ze ten firemni CA cert ktery meli importovany uz neni duveryhodny.

Chápu to tak, že ve veřejném prostoru zase nemám takovou volnost si vše dělat podle sebe a musím se přizpůsobit většině.

To asi nechápeš úplně správně. Nepřizpůsobuješ se většině, ale gůglu (a potažmo jabku).

hm, IETF, NIST a další tvrdí přesně tohle doporučení. Google si to jen změnil teď sám a podle reakcí ostatních to moc nekonzultovat a nekoordinoval.

mohou stát velice rychle zranitelné
To „velice rychle“ je ale v řádu let – to opravdu není důvod, proč zkracovat platnost koncových certifikátů na měsíce. Ostatně i kdyby tu přistáli přátelští mimozemšťané, kteří by nám omylem vyzradili, jak louskat některé kryptografické algoritmy, aby to bylo opravdu „velice rychle“, budeme mít stejně problémy s certifikáty autorit. Protože ty používají úplně stejné algoritmy, a za 30 dní je rozhodně nevyměníte.

v rámci certificate transparency se evidují všechny vydané certifikáty, snížením platnosti se sníží i náklady na provoz jejich seznamů, to dost výrazně.
Jako že když na tom seznamu budete mít víc položek, budou náklady na jeho provoz výrazně nižší? To těžko, ty náklady naopak budou vyšší.

Ač se Google rozhodl sám
Přímo v titulku zprávičky je napsáno, že návrh podal Apple. Minulé zkrácení prosadil také Apple, faktické zkrácení u velkého mnosžtví certifikátů zařídil Let's Encrypt. Shoda na tom, že je potřeba platnost webových certifikátů zkracovat, je poměrně široká.

Vůbec nejde o napadené a škodící weby. Jde o legitimní weby, kterým unikne privátní klíč. Kdyby dneska utekl privátní klíč nějaké bance, Googlu, Alze nebo nějakému menšímu e-shopu, tak se někdo dokáže vydávat za ten web přes rok – pokud by privátní klíč utekl hned na začátku. Banka nebo Google ty klíče snad mají dobře zabezpečené, nicméně už taková Alza má privátní klíče nejspíš uložené jako soubory někde na disku, možná na nějakých VPS. Takže pravděpodobnost úniku není úplně malá.

No a pak je tu samozřejmě specifický případ změny vlastníka domény, kdy původní vlastník může mít dál v držení certifikáty a privátní klíče přes rok po prodeji domény.

Jinými slovy, revokace je v koši, a nemá smysl to řešit jinak, než timeoutovat.

Smysl bude mít přidání otisku veřejného klíče do HTTPS DNS záznamu (což by u prohlížečů mohlo projít, padnou všechny výhrady proti DANE). Pak bude možné DV certifikáty od certifikačních autorit zrušit (a tím napravit historický omyl), používat self-signed certifikáty a od CA si případně nechat vystavovat OV certifikáty. V DNS ten certifikát půjde zneplatnit v řádu minut či hodin, podle nastavení DNS.

Seznamy revokovaných certifikátů jsou pro prohlížeče nepraktické, protože udržovat ve všech prohlížečích kompletní seznam všech odvolaných certifikátů není moc efektivní. Online se dotazovat na platnost certifikátu znamená prozrazovat, kdo se na jaký web dívá. A řešit to přikládáním OCSP potvrzení ke certifikátu ze strany serveru se Let's Encrypt nějak nechce, a vzhledem k tomu, že vydávají zdaleka nejvíc TLS certifikátů, bude to tak, jak se rozhodnou. Upřímně se jim moc nedivím, že se jim do toho nechce, protože pak se z té CA stává single point of failure – stačí tu CA odstavit na hodinu a velká část webu bude nedostupná.

Tenhle návrh mi nepřijde úplně praktický. Podle mne to bude náchylné na odmítání komunikace/ověření. Jakmile do hry vstoupí nějaká cache (případně cache proxy), bude se stávat, že certifikát na webu nebude souhlasit s otiskem v DNS.
Kromě toho by bylo potřeba se vypořádat s dalšími situacemi, například:
* certifikát na serveru s množstvím domén - změna by znamenala zápis do mnoha DNS,
* certifikát vystavený pro více serverů za loadbalancerem, tedy více platných certifikátů se stejným jménem serveru...

revokace ale nikdy nefungovala správně, stačilo zabránit stažení seznamu, což malý DDoS v vhodnou dobu poslouží dobře.

V CRL je uvedeno, do kdy musí být vydáno další CRL. Takže správně implementovaná revokace funguje správně – akorát je použitelná jen v případě, kdy máte na ověřování podpisu dost času. Používat na online komunikaci certifikáty, které z principu mají zastaralé údaje, je historický omyl. Správné řešení je mít klíče v DNS chráněném DNSSEC, ale než se k tomu v prohlížečích dopracujeme, bude to ještě chvilku trvat.

Nj ... to je tak, kdyz nekdo netusi co je to DNS ... vis jirsaku, to by krome toho klice potreboval totiz taky.

To ze si muze kdokoli nechat vystavit cert na temer libovolnou domenu, pokud ma pristup k nejakemu (libovolnemu) emailu na ni ani nemluve. Proc by nekdo jako krad nejaky webovej klic? Koho to zajima? Aha, presne nikoho.

No, to je ale podobné, pokud se někdo bude vydávat za banku, tak měsíc mu bude na záškodnictví taky asi stačit...

15. 10. 2024, 17:56 editováno autorem komentáře

Měsíc je doba, po kterou se ještě dají použít nějaká jiná opatření. Rok už by se dal řešit jedině tak, že by se ta doména přestala používat. Jinak samozřejmě ani ten měsíc není ideální – proto máme v PKI zabudován mechanismus revokace certifikátů. Který ovšem nebyl úplně stavět pro situaci, kdy je ověřovatel certifikátu v náramkových hodinkách a řeší se, aby se zobrazení webu nezdrželo o deset milisekund.

Nechapem, preco sa to riesi takouto zverinou, ked by stacilo pouzivat tu vec (nespominam si na nazov), ktora v TLS-ku spolu s certifikatom posle aj prislusnu OCSP odpoved?
Preco sa maniesto toho robia taketo zvrhle veci?

OCSP stapling. Protože Let's Encrypt plánuje podporu OCSP zrušit. Samotné OCSP v prohlížeči zpomaluje zobrazení stránky a prozrazuje CA, kdo který certifikát chce ověřit (tedy kdo se dívá na jaký web). Kdyby se to používalo správně, tedy že certifikátu důvěřuju teprve tehdy, když CA potvrdila jeho pravost, přestává web fungovat jako decentralizovaný systém a z CA se stává single point of failure. Pokud by se používal jen OCSP stapling, odstraní se problém únikem informací, kdo na jaký web přistupuje, ale single point of failure zůstává.

Prave tymto skracovanim vznika single point of faliture a to vo forme Lets Encrypt repektive Googlu (ktory kazdy rok meni pravidla tak aby vysachoval ostatne CA-cky). CA-ckok je vela a su decentralizovane, navyse ide fallbaknut na CRL.

Nemyslim si, ze by to spomalovalo nacitanie webu, ved o OCSP sa postara server a OCSp odpoved ma nejaky cas platnosti (radovo hodiny), takze ide znovupouzit.

Aj aj tento problem by slo riesit tym, ze ked sa teraz certifikaty akceptuju bez ohladu na revokaciu 40 dni, preco by sa nemohli akceptovat certifikaty platne 5 rokov s tym, ze od posledneho overenia platnosti ubehlo maximalne 40 dni?

Proc vysachovat CA? Vzdyt existuji i otevrene impleme ACME certifikacnich autorit, tedy nic nikomu nebrani si provozovat i svou vlastni (privatni) automatizovanou CA.

Ad OSCP a CRL... podivejte se do historie, jak to vznikalo. CRL bylo pred OSCP, pak se prislo s OSCP prave proto, ze CRL moc v praxi nefungovaly. Duvod odklonu od OSCP je primarne ochrana soukromi, aneb jeden problem se sice vyresil - ale na ukor vytvoreni problemu jineho.

Ne, zkracováním nevzniká single point of failure, protože i v té nejkratší variantě bude platnost certifikátu 45 dní, můžete ho měnit třeba po 30 dnech, takže budete mít pořád 15 dní na řešení případných problémů. Navíc máme ACME, takže přejít na jinou autoritu nebude problém – naopak to bude daleko snazší, než dnes (protože to budou muset implementovat všechny autority).

Google žádná pravidla nemění, navíc nemá žádnou certifikační autoritu.

V okamžiku navazování spojení nejde udělat fallback na CRL – to byste musel mít CRL už stažené.

O OCSP se nestará server, dělá to klient. Server se případně stará o OCSP Stapling, který je ovšem závislý na OCSP.

Myslel jsem si, že při OCSP Stapling je validita odpovědi v řádu minut. Teď jsem si to dohledal, že se běžně používá potvrzení s platností 7 dnů – tím pádem je to pro rychlé odvolání certifikátu stejně nepoužitelné.

Zavádět v prohlížečích novou závislost na ověřování platnosti certifikátu nedává smysl, když to nyní nefunguje a prohlížeče to používají buď volitelně nebo vůbec. Revokace certifikátů ze strany CA je zkrátka v online komunikaci nevyřešený problém a zkracování platnosti certifikátů je zatím jediné reálné řešení.

Takze kdyz si jirsaku veme ITk taky treba dovolenou, ty ze zakona narokovatelny 2 tydny, a automat failne, tak cert bez dalsiho proste expiruje ze?

Jsem jediný komu příjde 45 dní už příliš málo? Pak už podle mě nedává smysl vydávat certifikáty na víc než x hodin (třeba 24 hodin) a obnovovat ho prostě každý den.

Něco jako ten vtip „Dnes s vámi vyj***la sestra Tereza“? ;)

+1, Tereza ma dnes svatek :D

Pro certifikáty s platností 7-10 dnů CA nemusí udržovat CRL ani poskytovat status přes OCSP.

Certifikát s kratší platností než 7 dnů už žádnou úsporu pro CA nepřinese.

Jestli tohle projde, tak ACME 2 vypadá jako cesta kupředu / perspektivní způsob přežití.

A v takové situaci mi bude připadat bizardní, proč není nějaký kanonický ACME klient součástí např. OpenSSL a serverových vindózů (ať už IIS nebo přímo samotného OS). Proč se k tomu musí používat tvorba třetích stran. I když... sice se na jednu stranu mohu ošklíbat nad Pythonem (CertBot) nebo .NET (win-acme), na druhou stranu si nejsem vůbec jistej, jestli bych radši řešil budoucí bugy v 3rd-party projektu co má repo na GitHubu, vs. v nějaké standardní součástce Windows :-D vs. v nově vyvstalém problému 3rd-party softwaru po aktualizaci Windows... pick your poison. Možná je pozadu především můj mindset = provozovat si svůj vlastní server jakéhokoli druhu. Tzn. operátoři cloudových služeb se taky usmívají.

A proc by mel byt ACME soucasti OpenSSL? Jednak je to tak trosku proti unixove (KISS) filosofii, druhak OpenSSL neni zdaleka jedinou implementaci SSL/TLS. K tomu prvnimu staci uz jen dodat, ze je lepsi delat jednu vec a delat ji poradne... nez spoustu veci v ramci jedne binarky, kdy se pak dost zvetsuje prostor pro chyby.

Třeba vznikne systemd-openssl ;-)

Souhlas ohledně KISS/UNIX. Ona ta automatizační vrstva je nakonec dost samostatná.

Kanonický ACME klient je Certbot. Nevidím důvod, proč by měl být součástí knihovny OpenSSL, ani součástí Windows – vždyť je to aplikace jako každá jiná. No a pokud používáte rozumný software, žádný software třetích stran pro ACME nepotřebujete. Takový Caddy server má podporu ACME vestavěnou, funguje perfektně a v základní variantě bez jakékoli konfigurace. Prostě jenom nastartujete server. Nějaká kanonická implementace přibalená k něčemu by pro mne byla úplně zbytečná.

Ohledně Caddyho - to je masakr. Už to animované intro na homepagi projektu. Nenapadá mě netrollí komentář :-)
Moje zarezlé šedé závity dumají, kam se nám posouvá celý ten příběh o delegaci důvěry, o autenticitě a odpovědnosti. Co bude dál - indikační ikonka se zámečkem vedle adresního řádku bude mít barvu pozadí ze spojitého intervalu červená-zelená, a při přejetí myší sdělí vyskakovací bublina, kolik provozovatel webu utratí ročně za certifikát? :-)

Netuším, co jste se snažil svým komentářem říci.

Především si vážím Vašich reakcí - jsou vždycky technicky precizní a informačně hodnotné.

Z mé strany... narážím na obecný koncept "chain of trust", a jak se postupně rozpíjí. Pozoruji zvenčí z povzdálí ten vývoj PKI ekosystému:
- jenom důvěryhodné velké CA
- no dobře, tak přijmeme do klubu i pár levnějších hráčů
- ale ne aby si každý mohl zřídit veřejnou CA sám pro sebe a automaticky byl důvěryhodný a všeobecně uznávaný (v prohlížečích i jinde) - to zas ne
- pak vznikne software a "organizační mechanismus", který velkému provozovateli (hostingů apod.) dá možnost, objednávat certifikáty automatizovaně, téměř samotížně. Takový provozovatel uzavře rámcovou smlouvu s uznávanou CA. Takže následně CA vystavuje důvěryhodné certy všem požadavkům od daného velko-provozovatele hostingů.
- a pak tu automatizaci ve velkém přijme prostý lid (jako já), protože bez automatizace by člověk nedělal nic jiného než ručně aktualizoval certy.

Podle mého vzniká spektrum různě důvěryhodných certů - odstupňované podle toho, kolik peněz a úsilí držitel certu vynaložil na pořízení certu. Automatizace povede k "úsporám z rozsahu". Certy budou levnější. Přitom celý boj proti spamu a příbuzným činnostem je založený na tom, že se drží jakási nákladová bariéra, kterou se šmejdům nevyplatí překonávat.