Vlastní důvěryhodná CA

[Pavel...]

Tak som si pomyslel, ze si konecne spravim vlastnu CA, vyrobim z nej certifikaty pre web-server/emaily/NAS/...
Vyzera to viac menej funkcne a robi to co chcem. Ked teda vsade natlacim tu moju "CA" ako doveryhodnu .

Neskusal niekto vyriesit ten problem doveryhodnosti nejakym kupenym/inak ziskanym "CA-like" certifikatom s platnou certifikacnou cestou?
Zijem v tom, ze to nie je schodna cesta, ale radsej sa skusam blbo pytat, ako si casom nadavat, aky som idiot

[Reklama]

[Tomas-T]

Aby se stal certifikát od vaší CA pro někoho důvěryhodným, musíte:
- dostat do jeho systému svoji CA mezi důvěryhodné root CA (což dokážete zajistit v omezené skupině v níž máte admin práva, ale ne u neznámých třetích osob).
- Založit svoji CA (ne rootovou ale "podřízenou") na certifikátu jiné již důvěryhodné CA - takhle třeba začal LetsEncrypt, který pro svou první důvěryhodnou veřejnou CA použil certifikát od IdenTrustu. (Získat takový certifikát je ale administrativně obtížné a finančně drahé - protože ten kdo vám ho vydává, se vlastně zaručuje za vás a všechny vámi vydané certifikáty).

[Pavel...]

ano, tak nejak si to predstavujem .
A kedze nejdem zakladat novu verejnu CA, tak si myslim, ze moznost c.2. by bola znacne prehnana aktivita.

[luvar]

Dobry den, ospravedlnujem sa dopredu za "unesenie" temy, ale predpokladam, ze tie certifikaty, ktore podpisujete vlastnou CA sluzia primarne na intranete (domaca siet, teda ipecky z rozsahu 192.168.x.x, alebo podobne).

Osobne vnimam ako jednu moznost, aby na intranete boli validne certifikaty i pre navstevy (nahodny clovek z ulice s android telefonom napriklad), vystavovat si certifikaty od lets encrypt-u na domenu ako napriklad chladnicka.mojaDomacnost.root.cz. Takyto certifikat by musel ziskavat verejne dostupny server s vhodnym SW a nasledne sa certifikat stiahne na domace NASko a nasadi do reverzneho proxy (predpokladam, ze chladnicka nebude podporovat nahranie certifikatu)...

Nevyhoda je, ze clovek musi vlastnit nejaku domenu a raz za cas (validnost certifikatov lets encrypt), musi mat moznost spristupnit do Internetu server pre vydanie certifikatu pre "domace" sub-domeny.

Moja otazka je, nakolko je toto pouzivane riesenie a ake vyhody/nevyhody poskytuje oproti dvom uz spomenutym.

[jjrsk]

Zas tak "drahy" to neni, protoze ve skutecnosti se provozvatel CA nezarucuje za vubec nic, takze se cena pohybuje nekde od od 2 do 5kKc rocne.

Problem je spis v tom, ze to neni bezpecny - ty nijak neovlivnis, jestli korenovy CA nevyda jinej cert vlastne komukoli.

2luvar: Le je naprosto nepouzitelny uz proto, ze ty certifikaty musis vymenovat na mesicni bazi.

[Reklama]

[Filip Jirsák]

Neskusal niekto vyriesit ten problem doveryhodnosti nejakym kupenym/inak ziskanym "CA-like" certifikatom s platnou certifikacnou cestou?

Současný systém certifikačních autorit neumožňuje dávat žádná omezení na certifikační autority (technicky by to šlo, ale v tom systému to není implementované). Tj. kdybyste vaši certifikační autoritu dostal na úroveň ostatních certifikačních autorit, znamenalo by to, že všichni na celém světě budou té vaší certifikační autoritě důvěřovat, a to ať vydáte certifikát pro jakékoli jméno. Klidně byste mohl vydat certifikát pro google.com. Takže mezi ty důvěryhodné autority se dostane jen někdo, kdo prokáže, že má procesy i techniku nastavenou tak, že nevydá omylem (nebo jako důsledek útoku) certifikát někomu, komu by ho vydat neměl. Jenom dostat vaši certifikační autoritu technicky na takovou úroveň by bylo velmi drahé (rozhodně byste nemohl mít privátní klíče autority v souboru na disku, ale musely by být v certifikovaném HSM), drahý by byl i návrh procesů a jejich následná certifikace.

Mohlo by se zdát, že schůdnější cesta by byla nesnažit se dostat přímo na seznam důvěryhodných certifikačních autorit, ale aby certifikát vaší certifikační autority křížově podepsala jiná certifikační autorita. Tak, jak to měl třeba Let's Encrypt, nebo jako to používá třeba Google pro své certifikáty. Jenže ani v tomto případě to nebude lepší, protože certifikační autorita, která by vám certifikát vaší CA podepsala, nemůže nijak omezit, jaké certifikáty byste mohl vydávat. Ale měla by za vámi vydávané certifikáty plnou odpovědnost. Tedy by na vás měla stejně vysoké nároky, jaké jsou kladené na ni samou.

[Filip Jirsák]

Osobne vnimam ako jednu moznost, aby na intranete boli validne certifikaty i pre navstevy (nahodny clovek z ulice s android telefonom napriklad), vystavovat si certifikaty od lets encrypt-u na domenu ako napriklad chladnicka.mojaDomacnost.root.cz. Takyto certifikat by musel ziskavat verejne dostupny server s vhodnym SW a nasledne sa certifikat stiahne na domace NASko a nasadi do reverzneho proxy (predpokladam, ze chladnicka nebude podporovat nahranie certifikatu)...

Nevyhoda je, ze clovek musi vlastnit nejaku domenu a raz za cas (validnost certifikatov lets encrypt), musi mat moznost spristupnit do Internetu server pre vydanie certifikatu pre "domace" sub-domeny.

Moja otazka je, nakolko je toto pouzivane riesenie a ake vyhody/nevyhody poskytuje oproti dvom uz spomenutym.

Ano, musíte mít vlastní doménu. Do internetu žádný server pro vystavení certifikátů vystavovat nemusíte, stačí DNS. Let's Encrypt má možnost ověřovat vydání certifikátu přes DNS, takže tu veřejnou část zajistí DNS server – a ten máte typicky k dispozici od toho, kde jste doménu koupil (a nebo jsou DNS hostingy zdarma). Ideální je, když ty DNS záznamy můžete spravovat přes nějaké všeobecně známé API, abyste to nemusel dělat ručně, ale mohl nechat celý proces získávání certifikátů dělat automatizovaně.

Já pro tohle používám Caddy server, který umí hned v základu získávat a obnovovat certifikáty protokolem ACME (tedy např. od Let's Encrypt). Jediné, co jsem musel udělat, je změnit výchozí konfiguraci, že se certifikáty nevalidují přes HTTP ale přes DNS. Jedním z DNS providerů, se kterými už umí Caddy komunikovat, je Cloudflare. Takže doména je hostovaná (zdarma) na Cloudflare, vytvořil jsem k ní API key, ten jsem zadal do konfigurace Caddy a ten se stará o výměnu klíčů. Caddy běží jen ve vnitřní síti a slouží jako reverzní proxy ke všem HTTPS službám.

Za mne je to vlastně jediné použitelné řešení. DNS záznamy jsou všude stejné, tj. nestane se mi, že by třeba mobil byl na mobilní síti, kde by si nakešoval odpověď „DNS záznam neexistuje“, pak přešel do vnitřní sítě, kde se ten DNS záznam teoreticky přeloží, ale s mobilem budu muset čekat, než vyprší cache. Používá se normální všeobecně důvěryhodná certifikační autorita. Což je velká výhoda proti vlastním CA. Ono nacpat svou vlastní CA do desktopového systému je celkem jednoduché. Pak zjistíte, že Firefox má vlastní seznam důvěryhodných CA. Dostat do do mobilního OS je trošku složitější, ale jde to. Pak k vám přijde někdo na návštěvu, a jemu už asi vlastní CA do mobilu instalovat nebudete. A pak třeba začnete řešit vývoje, Node.js nebo Docker, a zjistíte, že v Node.js byste vlastní autoritu musel přidávat na několik míst, a cpát vlastní autoritu do Docker image běžícího v jiném Docker image už vůbec nechcete. Chápu, že někde vlastní CA ještě dobíhají, ale určitě bych teď nastavěl vlastní CA pro běžný provoz uživatelské sítě – tam už jedině ta varianta s ACME protokolem a DNS validací při vydání certifikátu.

[Pavel...]

Osobne vnimam ako jednu moznost, aby na intranete boli validne certifikaty i pre navstevy (nahodny clovek z ulice s android telefonom napriklad), vystavovat si certifikaty od lets encrypt-u na domenu ako napriklad chladnicka.mojaDomacnost.root.cz.

ano, keby som staval novu siet na zelenej luke, tak nad tym vazne uvazujem. Vyhody su zrejme. Pracnost pre jestvujucu siet je neprijemna, na druhej strane uznavam, ze sa to da postupne tlacit.

Nevyhody vnimam dve:
- dlzka platnosti. Proces pri Let's encrypt pri jej kratkej platnosti certifikatov musi byt automatizovany. Ked si spravim vlastny certifikat, tak mozem ist od 2 rokov vyssie a nemusim sa trapit zo zariadeniami, ktore nie su rozumne automatizovatelne.
- emaily. Netusim ci by sa to vobec dalo rozumne rozbehat. Jedna z hlavnych motivacii toho co teraz robim je to, ze na emaily vyrobim 10 rocne certifikaty.

No ved uvidi sa, vzdy mozem postupne zacat tlacit Let's Encrypt ked usudim, ze je to praktickejsie.

[Filip Jirsák]

- dlzka platnosti. Proces pri Let's encrypt pri jej kratkej platnosti certifikatov musi byt automatizovany. Ked si spravim vlastny certifikat, tak mozem ist od 2 rokov vyssie a nemusim sa trapit zo zariadeniami, ktore nie su rozumne automatizovatelne.

Záleží na tom, jakým způsobem s těmi těžko automatizovatelnými zařízeními komunikujete. Pokud z prohlížeče, bál bych se té délky platnosti certifikátu. Prohlížeče postupně zkracují maximální dobu platnosti certifikátu, kterou akceptují. Pro privátní CA mají prohlížeče ohledně certifikátů dost výjimek, ale nikde není záruka, že i tam začnou platnost zkracovat (a vlastně nevím, zda už teď nějaký limit neuplatňují). Pokud je ten protokol HTTPS, je zase jednoduché to zařízení strčit za proxy, která se postará o HTTPS, a mezi proxy a zařízením ať se komunikuje třeba dálnopisem (a nebo self-signed certifikátem s platností 100 let, který bude zadaný napevno v konfiguraci toho proxy serveru).

Samozřejmě pokud se s tím zařízením pracuje nějakým jiným protokolem, ideálně TLS s oboustrannou autentizací, a certifikát s privátním klíčem tam musíte přinést pokud možno osobně na USB flash disku, moc se s tím toho dělat nedá…

- emaily. Netusim ci by sa to vobec dalo rozumne rozbehat. Jedna z hlavnych motivacii toho co teraz robim je to, ze na emaily vyrobim 10 rocne certifikaty.

Předpokládám, že vám jde o podepisování e-mailů uvnitř organizace. To je trochu jiná disciplína a tam vám stačí, aby tomu kořenovému certifikátu důvěřovaly Outlooky na pracovních stanicích, a ty si to stáhnou z AD. Tím odpadá ten největší problém vlastní CA, že když zjistíte milion míst, kde je potřeba mít kořenový certifikát jako důvěryhodný, objeví se milion první místo, kde chybí. (A zajímalo by mne, zda už certifikáty pro šifrování z AD v Outlooku prostě fungují, nebo zda je potřeba to stále zaříkávat, aby si Outlook ráčil stáhnout aktuální certifikát protistrany. Protože když jsme to ještě používali, vždy několik dní před ostrým použitím probíhala secvičná, aby se zajistilo, že Outlook odesílatele vidí v AD ten samý certifikát pro šifrování, který má příjemce nastavený pro dešifrování.)

[Pavel...]

Záleží na tom, jakým způsobem s těmi těžko automatizovatelnými zařízeními komunikujete. Pokud z prohlížeče, bál bych se té délky platnosti certifikátu. Prohlížeče postupně zkracují maximální dobu platnosti certifikátu, kterou akceptují. Pro privátní CA mají prohlížeče ohledně certifikátů dost výjimek, ale nikde není záruka, že i tam začnou platnost zkracovat (a vlastně nevím, zda už teď nějaký limit neuplatňují).
...

Limit je 825 dni, ako som zistil vramci nastavovania celeho procesu

Viac menej sa spolieham na to, ze si tymto kupujem cas. Kym definitine zabiju HTTP  este chvilu potrva a az potom sa aktivisti vrhnu do dalsieho kroku.

Předpokládám, že vám jde o podepisování e-mailů uvnitř organizace. .... (A zajímalo by mne, zda už certifikáty pro šifrování z AD v Outlooku prostě fungují...)

Nie, nefunguju preto chcem zamenit rocne certifikaty s platnou cestou za 10 rocne bez platnej cesty .
 

[Filip Jirsák]

Já bych v takovém případě stejně volil variantu vlastní CA jen pro osobní šifrovací certifikáty, ACME (třeba nejspíš Let's Encrypt) pro TLS certifikáty. Je to logické rozdělení, Let's Encrypt nebo ZeroSSL vám vystaví jen serverové certifikáty, osobní musíte mít odjinud. A pokud jde o nějaký interní provoz, asi nebudete chtít všem zúčastněným kupovat komerční osobní certifikáty – pro ně tedy použijete interní CA.

Nie, nefunguju

No jo no, když ono udělat službu, do které strčíte e-mailovou adresu a vypadne z ní k ní přiřazený certifikát, to není jen tak. To je věda. Ale já myslím, že to Microsoft jednou spraví – hned po té, co při odpovědi na e-mail, který jsem sám posílal, přestane jako příjemce nastavovat mě, ale nastaví tam původní adresáty.

[jjrsk]

...
Nie, nefunguju preto chcem zamenit rocne certifikaty s platnou cestou za 10 rocne bez platnej cesty .

Hele, to by me zajimalo, co ti na tom nefunguje? Je to uz par patku, ale s kolegou sem to testoval, a vypadalo to celkem funkcne (teda krom toho, ze se to da realne pouzit jen interne). Normalne sem do GPO nastavil at to generuje user certifikaty, a kdyz si odesilatel nastavil, ze chce mail podepsat, podepsalo se. Odpoved se dala uz i zasifrovat ... a fungovalo to. Testovali sme to mezi Outlookama a TB + eM + nejakej androidi klient.

Prakticky nejzasadnejsi problem byli webmailisti, to je nogo zona.

[Filip Jirsák]

Hele, to by me zajimalo, co ti na tom nefunguje? Je to uz par patku, ale s kolegou sem to testoval, a vypadalo to celkem funkcne (teda krom toho, ze se to da realne pouzit jen interne). Normalne sem do GPO nastavil at to generuje user certifikaty, a kdyz si odesilatel nastavil, ze chce mail podepsat, podepsalo se. Odpoved se dala uz i zasifrovat ... a fungovalo to. Testovali sme to mezi Outlookama a TB + eM + nejakej androidi klient.

Prakticky nejzasadnejsi problem byli webmailisti, to je nogo zona.

Zkoušel jste výměnu šifrovacího certifikátu? Po výměně certifikátu uživatelem trvalo blíže neurčenou dobu, než mohl odesílatel (na tomtéž Exchange serveru) použít pro šifrování nový certifikát. Do té doby se používal buď starý, nebo Outlook tvrdil, že adresát nemá žádný certifikát pro šifrování. Pomáhalo jenom „zkusíme to zítra“.

Celá ta šaráda s ukládáním certifikátů někam na server je právě proto, aby to šifrování fungovalo hned od prvního e-mailu. To, že mi odesílatel pošle svůj šifrovací certifikát a já mu pak můžu odpovědět šifrovaně, to umí i GPG nebo openssl. Přidaná hodnota Outlooku měla být právě v tom, že si umí ze serveru stáhnout certifikát i pro někoho, s kým jsem do té doby vůbec nekomunikoval. Teoreticky.

[Pavel...]

Ano, problem Outlooku, domeny a certifikatov je v tom, ze nefunguje bezproblemovo uvodny setup. Vymena certifikatu je z praktickeho hladiska "nastavujem to cele este raz".
Ked mate hrst zamestnancov a kazdemu kazdy rok musite nastavovat novy certifikat, tak je to otravne.
Hlavny problem je v managemente tych cerfifikatov u prijmatelov. Ten co posiela sifrovany email, musi vybrat ten isty ako ten co pouzije prijmatel.  A Outlook je schopny pouzit nahodny (ak nieco vobec najde) schovany certifikat a protistrana sa dozvie "email sa neda precitat".
Pokial sa to pouziva iba na podpisovanie je to relativne bezproblemove.

Kapitola sama o sebe je, ze ked mate rocny certifikat a sifrovane historicke emaily, musite vsetky tie certifikaty mat vzdy k dispozicii.

Za tie roky:
- som nanasiel sposob ako to bezproblemovo prevadzkovat
- som nenasiel nikoho kto by mi povedal, ako to bezproblemovo prevadzkovat

Pouzivame to interne a s jednou protistranou, protistrana si na zaciatku zvolila to co teraz skusam. Zda sa mi, ze ich riesenie funguje lepsie .

---

Uznavam, ze ked uz mam to "vlastne CA", tak k tomu pristupujem sposobom "ked mate v ruke kladivo, vsetko vyzera ako kliniec". Minimalne sa to lahko vsade nasadzuje. A spravca si pochvaluje, ze mu browser nehadze warning pocas prihlasovania k NAS
Jasne, verejne dostupne veci maju normalne certifikaty s platnou cestou.

[Bugsa]

Pavel... nechci se tě nijak dotknout, ale řešíš primitivní problém tou nejkomplikovanější cestou....

Nemůže být nic jednoduššího než všechny intranetové servery schovat ze reverzní proxy. Ta může být třeba na serveru Caddy, který certifikáty AUTOMATICKY získává a obnovuje. Nebo cronem spouštět program "dehydrated", který dělá to samé a použít libovolný web server. Po obnově certifikátu lze spustit skript, který web server a mail server reloadne a tím se použije nový certifikát.

Na e-mailovém serveru používám Let's Encrypt od té doby co existuje a nikdy s tím nebyl problém. Ani mě nenapadá důvod proč by to problém měl být.

Vlastní CA je prostě naprostý nesmysl.