Vlákno názorů k článku Google chce omezit platnost certifikátů na 90 dnů, změna zřejmě přijde brzy od RRŠ - Co čtvrt roku absolvuji martyrium při výměně certifikátů...
-
Co čtvrt roku absolvuji martyrium při výměně certifikátů (LE) na e-mailovém serveru - to sice udělá poskytovatel, ale následně musím ve všech zařízeních v Thunderbirdu potvrdit, že opravdu věřím certifikátu, který je vystavený pro jinou doménu, než ze které odesílám poštu. (Musím používat SMTP server poskytovatele, ale ten není ve stejné doméně, ze které odesílám e-maily.)
Představa, že tohle budu absolvovat co dva týdny... Za tak krátkou dobu to stihnu sotva potvrdit na všech strojích! -
Ondřej CaletkaZlatý podporovatelTo vypadá, že máte špatně nastavené jméno SMTP serveru - to je totiž to, co Thunderbird kontroluje proti obsahu SAN v certifikátu. Podívejte se tedy do toho certifikátu na doménová jména uvedená jako SAN a nastavte jméno svého SMTP serveru na jedno z nich. Z jaké domény odesíláte poštu nehraje žádnou roli.
-
V tomhle máte pravdu, přesně v tom je ten problém: abych mohl poslat e-mail, musím se hlásit na server pod jménem, které v tom certifikátu není uvedené.
Problém je, že když změním jméno serveru, aby odpovídalo certifikátu, odmítne mne. Podle podpory je řešením: dát tam předepsané jméno serveru a povolit explicitně výjimku...
Ze své strany moc nezmůžu a měnit poskytovatele služby se mi kvůli tomu nechtělo (nechce) - jednou za čtvrtrok to nebylo tak hrozné... -
DannyStříbrný podporovatelTakovy scenar zni dost nepravdepodobne - ze by se i hostname nejak vynucoval a pritom k tomu neexistoval validni certifikat. Co se podelit o vice detailu, treba alespon jmeno toho poskytovatele? A co na to jejich technicka podpora?
-
Nepravděpodobně... - poskytovatelé služeb jsou schopni mít nastavena různá zvěrstva, zejména v případě, kdy větší ryba sežrala menší, která to podědila po úplně malé společnosti, u které jsem to zařizoval před mnoha lety. Jak to postupně migrují na svá řešení, tak se ty konfigurace všelijak kazí.
Řešením by (prý) bylo ty schránky úplně zrušit a znova založit na jejich novém serveru, ale do toho se mi nechce, je tam dost historie a archivů,, profilů...
(Jmenovat je záměrně nebudu - radši hledámsmírné řešení
, než veřejněpranýřuju
.) -
DannyStříbrný podporovatel
Aha, takze jste si prisel zanadavat na neco, kde prava pricina ve skutecnosti neni to, ze se certifikaty obmenuji s vetsi periodicitou - na co nadavate jsou jen nasledky vasich vlastnich rozhodnuti ;-)
-
Fuj.
Šlo mi spíše o to, že certifikáty (a jejich výměna) se zdaleka netýkají jen webovek.
Z jiného soudku: máme v práci aplikaci, která na veřejných certifikátech stojí, ale výměna je proces na cca dva týdny (tři dny jen zrychlené schválení žádosti v rámci firmy, jeden den na získání certifikátu, předání dodavateli/protistraně další den, nasazení a kontrola na obou koncích - to celé dvakrát, pro testovací a produkční prostředí...).
Jednou do roka se to dá v pohodě zvládnout, ale pokud by platnost byla pouhé dva týdny... -
DannyStříbrný podporovatel
Za nevhodny design aplikace fakt X.509 nemuze... ano, samotna moznost vystavovat mnohalete certifikaty v kombinaci se chticem dodavatele byt jaksi nepostradatelnym vedla ke vzniku vselimoznych bastlu. Vsak dodavateli platite, ne? Tak at to udela poradne, ne? Nebo si zvolte jine reseni, kterym vzpupneho dodavatele jednoduse odstavite od jeho penezovodu. Tady se bavime o hlasovani penezenkou a ne o realnych technickych problemech...
-
Tady nejde o
chyby X.509
, ale o to, že firemní proces nepočítá s tak rychlou obměnou - a ten certifikát (který nelze jednoduše nahradit LE) není zadarmo, ale za pár €. Takže nákup musí někdo schválit a rozhodně není žádoucí, aby si o to požádal každý technik na konci firemního potravního řetězce, natož, aby to dělal automat. Pak by, pokud by se cena nezměnila, stouply náklady zhruba pětadvacetinásobně.
Schválit nákup čehokoliv prostě ve velké firmě chvíli trvá - a ty tři dny jsou ještě poměrně dost svižné tempo!
(Takový nákup sluchátek, to je teprve ta správná atrakce - k tomu se chce vyjádřit úplně každý manažer, protože každý manažer moc dobře ví, jak vypadají sluchátka, a dokáže si představit, kolik by tak mohla stát. Naproti tomu serverovému certifikátu nerozumí z managorů nikdo, to je příliš abstraktní komodita. Takže dokud to není moc často, tak to prostě bez ptaní schválí...) -
My zas v našom korporáte problém s platbou za certifikáty nemáme, a na vystavovanie verejných certifikátov od DigiCertu je poloautomatický proces, ale máme jednu enterprise aplikáciu, ktorá tie certifikáty (potrebujeme od verejnej CA, lebo pár ľudí od zákazníka sa potrebuje pripájať na webové UI toho molocha, a majú nejaké prísne vlastné pravidlá na prístup k HTTPS) používa aj na nejakú vnútornú komunikáciu a vyžaduje (odskúšané) kompletný downtime (bežne stačí vypnúť jeden node z dvoch a nastavovať po jednom) na ich výmenu. Pol hodinky, keď sa darí.
Keď to malo byť raz za rok, to sa ešte dá zniesť, ale 90 dní je už povážlivo nepríjemné. Asi to budú vendorovi otrieskávať o hlavu viacerí, ale neviem, či bude postup tej výmeny vedieť zmeniť len tak nejako jednoducho... -
Filip JirsákStříbrný podporovatelŠlo mi spíše o to, že certifikáty (a jejich výměna) se zdaleka netýkají jen webovek.
Ale web v tom není nijak speciální. Pořád to znamená, že klient chce komunikovat se serverem s nějakým DNS názvem, dostane od něj certifikát prokazující, že server tento DNS název může používat a ověří, zda se jedná o důvěryhodný certifikát a odpovídá danému jménu. A server musí takový certifikát mít i s privátním klíčem, přičemž vydání a nahrazení certifikátu je vhodné zautomatizovat.máme v práci aplikaci, která na veřejných certifikátech stojí,
Záleží na tom, co je to za certifikáty. Jestli certifikáty prokazující DNS název, fyzickou osobu, právnickou osobu, aplikaci… -
Filip JirsákStříbrný podporovatel
To je ale problém chybné konfigurace, buď serveru nebo klienta (nebo obojího). Ale to by bylo potřeba znát přesný popis chyby – to, co jste napsal, je poněkud zmatené.
