Fórum Root.cz
Hlavní témata => Server => Téma založeno: hknmtt 14. 12. 2022, 11:01:25
-
Co je dnes "mainstream" sposob nasadenia https na webove aplikacie?
Problem dnes je rozsirenost Let's Encrypt a jeho certifikatov s kratkou zivotnostou, kedy nestaci raz za rok, dva.. manualne nahodit novy certifikat co je 5 minutova robota. Nie, dnes sa musi investovat cas a peniaze do vyvoja automatizovaneho riesenia ktore musi riesit challenge, uschovu, reload certifikatov a v spranvom case cely proces opakovat.
Ak si vezmem ze 99% pripadov je http challenge, tak nie je mozne vypnut port 80, cize aplikacia musi bezat na dvoch portoch a odlisit ci ide o LE na http a podla toho presmerovat na https verziu alebo spracovat LE challenge.
Dalsie riesenie je skryt aplikaciu za vlastnu lokalnu proxinu(traefik, nginx, haproxy..), takze aplikacia sa odbremeni od https a dvoch spojeni, co je super, lenze zase ta proxy treaz musi routovat 99.99999% dat na prazdno, a zrat hw, len kvoli LE ktore pride raz tri mesiace. Ale zase to riesi sama uz, takze aplikacia samotna sa o nic starat nemusi. Ale zase na produkcii to prinasa dalsiu starost - namiesto jednej binarky a jej konfiguracie je vyzadovana dalsia binarka pre tuto proxinu a konfiguracia pre nu a dodatocne znalosti pre spavnu konfiguraciu a prevadzku.
Tretia moznost je pouzit externu proxinu typu CloudFlare ktora kompletne odbremeni od riesenia HTTPS za cenu ze prevadzka zo serveru na cloudflare je nesifrovana(prakticky mitm) a teda cloudflare ma plny pristup k datam uzivatelov a taktiez pod kontrolou komplet cele DNS. A ked sa rozhodne ze sa im nepacite, tak vas vypnu a mate mozno aj niekolko-hodinovy vypadok. Takze taktiez nie idealna situacia.
Preto ma zaujima co dnes fici ako najpouzivanejsi postup?
-
Reverzní proxy řeší nejen HTTPS, ale i věci jako Slow lorris.
-
Manuální obnovování certifikátů je peklo, kvůli kterému jsem v dobách před Let's Encrypt vůbec HTTPS nenasazoval. Vede to k chybám a pokud máte stovky webů, tak se z toho zblázníte. Automatizace je cesta, která to celé řeší stylem „nasaď a zapomeň“. Není potřeba nic vyvíjet, všechno je hotové, připravené k nasazení. Já na produkci používám ACME.sh (https://www.root.cz/clanky/acme-sh-snadna-cesta-k-certifikatu-od-let-s-encrypt/), nasazení je jednoduché, dá se krásně automatizovat.
Na portu 80 mi webové servery samozřejmě taky poslouchají, ale je tam triviální konfigurace, která jen přesměruje příchozího na 443. Tam se pak odehrává všechno ostatní, nic složitého na tom není.
Pochopitelně je nutné to celé monitorovat, protože se může stát, že něco selže a třeba se kvůli vypadlé subdoméně přestanou obnovovat certifikáty. ACME.sh obnovuje ve výchozím stavu ve chvíli, kdy je platnost certifikátu kratší než 30 dnů, monitoring mi začne křičet, pokud platnost klesne pod 14. Je tam tedy dost času na řešení. V průběhu let se problém stal asi jen dvakrát a byla to drobnost, která byla okamžitě vyřešená. Jinak s tím není vůbec žádný problém.
-
nepočítám, když si platíš hosting a řeší to za tebe. Kolem mě a na mých projektech je standard terminovat https na bráně (nginx, haproxy, f5 či cokoliv), vydávat certifikáty přes DNS challenge (s třeba delegovanými TXT záznamy na tvoji infra), nasazovat automaticky a kontrolovat, že je nasazený. Pro interní komunikaci (aplikace <> brána) používat interní CA a interní ceritifikáty.
Reverzní servery jako třeba Caddy umí dokonce si sami certifikát vystavit, takže ani v malém nasazení to není nikterak komplikované.
-
Není žádný jeden způsob, který by se používal řádově víc, než jiné. Vychází se z toho, zda už něco máte, nebo to stavíte od nuly. Třeba když už máte rozchozený nginx a nechcete řešit nic jiného, zprovozníte automatizaci vydávání certifikátů pro nginx. Když se vám to hodí, můžete předřadit službu jako Cloudflare a s tím získáte i HTTPS. Když ještě server nemáte nebo chcete webový stack aktualizovat, použijete třeba Caddy server, který už má správu certifikátu zabudovanou v sobě.
Řešit výměnu certifikátů ručně dnes nedává smysl. HTTP nemusíte řešit jenom kvůli vydávání certifikátů – prohlížeče pořád adresu bez protokolu doplňují (nepochopitelně) protokolem HTTP, takže pořád potřebujete mít přesměrování z HTTP na HTTPS. A vydávání certifikátů nemusíte nijak zvlášť ošetřovat, LE si s přesměrováním poradí (pokud je udělané správně a přesměrováváte plnou adresu ne stejnou adresu s HTTPS).
-
Jak řešit certifikáty pro HTTPS na zařízeních, na kterých nemůže běžet ACME klient (tiskárny, routery...)? Vlastní CA mít nechci.
Je správná cesta generování certifikátů a DNS-challenge na Raspberry Pi a distribuce certifikátů na koncové za´rizení pomocí jejich API (pokud mají)?
-
Jak řešit certifikáty pro HTTPS na zařízeních, na kterých nemůže běžet ACME klient (tiskárny, routery...)? Vlastní CA mít nechci.
Je správná cesta generování certifikátů a DNS-challenge na Raspberry Pi a distribuce certifikátů na koncové za´rizení pomocí jejich API (pokud mají)?
Priama implementacia v aplikacii. Nie je to moc zlozite. Ak sa bavime o LE. Aj ked neviem co s tymto maju tlaciarne&spol.
-
Jak řešit certifikáty pro HTTPS na zařízeních, na kterých nemůže běžet ACME klient (tiskárny, routery...)? Vlastní CA mít nechci.
Je správná cesta generování certifikátů a DNS-challenge na Raspberry Pi a distribuce certifikátů na koncové za´rizení pomocí jejich API (pokud mají)?
To je jedna možnost. Druhá možnost je před ta zařízení dát reverzní proxy, která vyřeší certifikáty, a se zařízením bude komunikovat buď přes HTTP, nebo přes HTTPS se selfsigned certifikátem s dlouhou platností.
-
Manuální obnovování certifikátů je peklo, kvůli kterému jsem v dobách před Let's Encrypt vůbec HTTPS nenasazoval. Vede to k chybám a pokud máte stovky webů, tak se z toho zblázníte. Automatizace je cesta, která to celé řeší stylem „nasaď a zapomeň“. Není potřeba nic vyvíjet, všechno je hotové, připravené k nasazení. Já na produkci používám ACME.sh (https://www.root.cz/clanky/acme-sh-snadna-cesta-k-certifikatu-od-let-s-encrypt/), nasazení je jednoduché, dá se krásně automatizovat.
To vse je hotove a da se krasne automatizovat funguje tak maximalne, pokud mate dany certifikat na jednom serveru/sluzbe. Co v pripade, kdy certifikat je na X serverech? To uz to nasazeni neni tak jednoduche, ze?
-
Pro interní komunikaci (aplikace <> brána) používat interní CA a interní ceritifikáty.
A co v pripade, ze se vola aplikacni server mimo cestu skrz branu? To se vypina validace certifikatu?
Priklad:
1] haproxy (example.com certifikat)
2] 3x web server (interni certifikat)
3] zaslani requestu primo na web serveru pro domenu example.com (napr. curl s parameterem --resolve)
-
Aj ked neviem co s tymto maju tlaciarne&spol.
Ještě jsem nepotkal tiskárnu, do které by šel doinstalovat (bez hackování) ACME klient. Vy nějakou takovou znáte? U routerů to stejné, pokud to je obyčejný TP-Link se stock firmwarem a ne třeba MikroTik a nebo něco s OpenWRT.
-
To je jedna možnost. Druhá možnost je před ta zařízení dát reverzní proxy, která vyřeší certifikáty, a se zařízením bude komunikovat buď přes HTTP, nebo přes HTTPS se selfsigned certifikátem s dlouhou platností.
Vlastní CA se chci vyhnout.
-
Manuální obnovování certifikátů je peklo, kvůli kterému jsem v dobách před Let's Encrypt vůbec HTTPS nenasazoval. Vede to k chybám a pokud máte stovky webů, tak se z toho zblázníte. Automatizace je cesta, která to celé řeší stylem „nasaď a zapomeň“. Není potřeba nic vyvíjet, všechno je hotové, připravené k nasazení. Já na produkci používám ACME.sh (https://www.root.cz/clanky/acme-sh-snadna-cesta-k-certifikatu-od-let-s-encrypt/), nasazení je jednoduché, dá se krásně automatizovat.
To vse je hotove a da se krasne automatizovat funguje tak maximalne, pokud mate dany certifikat na jednom serveru/sluzbe. Co v pripade, kdy certifikat je na X serverech? To uz to nasazeni neni tak jednoduche, ze?
A proč by to někdo dělal? To dává smysl při ruční obnově certifkátu, kdy je stejný certifikát všude proto, aby stačilo generovat jeden a pak se to jen rozkopíruje. Teď každý server může sám nechat vystavit svůj vlastní unikátní certifikát.
A pokud máte nějaké velké komplikované prostředí, kde to sdílení z nějakého důvodu fakt potřeba je, a kde se to nedá řešit interní CA + proxy, co to přebalí, jak to většinou dělají velké firmy... no, pak si můžete tu automatizaci upravit. Protože to už pak asi není garážová firmička se dvěma zaměstnanci.
Plus, vždycky je tu možnost vrátit se do starých časů, vytáhnout šekovou knížku a zaplatit si za certifikát s dvouletou platností a ruční správou. Let's Encrypt není jediný zdroj certifikátů.
-
Jak řešit certifikáty pro HTTPS na zařízeních, na kterých nemůže běžet ACME klient (tiskárny, routery...)? Vlastní CA mít nechci.
Je správná cesta generování certifikátů a DNS-challenge na Raspberry Pi a distribuce certifikátů na koncové za´rizení pomocí jejich API (pokud mají)?
zpravidla nenechávám si vydávat cert koncovým zařízením (nechci, aby za to mělo odpovědnost). Takže vydání přes DNS na extra zařízení, uložení do šifrované db (např. hasicorp vault, ale stačí klidně i gpg šifrování) a distribuce na daná zařízení. Pokud jde o routery, tak využívám buď jejich http api, mngm rozhraní nebo seriový port a cert jim tam nakopíruji, zpravidla se vždy nějaká cesta najde. Držím se ale pravidla, že pouze zařízení, které jsou určena pro veřejnou komunikaci mají veřejný certifikát, ostatní interní.
-
To je jedna možnost. Druhá možnost je před ta zařízení dát reverzní proxy, která vyřeší certifikáty, a se zařízením bude komunikovat buď přes HTTP, nebo přes HTTPS se selfsigned certifikátem s dlouhou platností.
Vlastní CA se chci vyhnout.
Ta reverzní proxy samozřejmě může vystavovat certifikáty od LE nebo jiného poskytovatele používajícího ACME standard. Třeba Caddy server takhle funguje a zprovoznění znamená stažení binárky a napsání asi 1 řádku konfigurace.
-
Co je dnes "mainstream" sposob nasadenia https na webove aplikacie?
Moj mainstream je AWS. Webove aplikacie su za AWS ALB, ktory ma TLS cert vydany AWS z ACM. A to je vsetko. TLS cert je pre mna iba manazovana AWS sluzba (vratane obnovy). Mimochodom, TLS certifikaty vydane AWS su zdarma. Takze nemam ziadne tvoje problemy.
Dalsie riesenie u teba, by som videl v nasadeni aplikacii ktore si vedia reloadnut TLS bez restartu samotnej aplikacie a ich certy budes manazovat svojim oblubenym nastrojom (puppet, ansible, ...) centralne.
-
zpravidla nenechávám si vydávat cert koncovým zařízením (nechci, aby za to mělo odpovědnost). Takže vydání přes DNS na extra zařízení, uložení do šifrované db (např. hasicorp vault, ale stačí klidně i gpg šifrování) a distribuce na daná zařízení. Pokud jde o routery, tak využívám buď jejich http api, mngm rozhraní nebo seriový port a cert jim tam nakopíruji, zpravidla se vždy nějaká cesta najde. Držím se ale pravidla, že pouze zařízení, které jsou určena pro veřejnou komunikaci mají veřejný certifikát, ostatní interní.
Co vás vede k tomu, že koncová zařízení by neměla řešit certifikáty pro sebe? Podle mě by privátní klíč pokud možno neměl opustit koncové zařízení.
Proč by zařízení přístupná pouze z interní sítě nemohla mít LE certifikát?
Ta reverzní proxy samozřejmě může vystavovat certifikáty od LE nebo jiného poskytovatele používajícího ACME standard. Třeba Caddy server takhle funguje a zprovoznění znamená stažení binárky a napsání asi 1 řádku konfigurace.
Nerozumím. Co bude reverzní proxy vystavovat a komu?
-
Nerozumím. Co bude reverzní proxy vystavovat a komu?
Reverzní proxy nechá třeba u LE nebo ZeroSSL vystavit certifikát třeba na tiskarna.example.com, bude terminovat HTTPS provoz pro tuhle adresu a bude ho přeposílat na skutečnou tiskárnu protokolem HTTP nebo HTTPS se selfsigned certifikátem.
Třeba Caddy umí i zprostředkovat vydání certifikátu pro jiné zařízení (tj. funguje i jako ACME server), ale to v tomto případě není potřeba, protože byla řeč o situaci, kdy to zařízení neumí ACME. Nevíc v případě toho zprostředkování vydání certifikátu by nebyla potřeba reverzní proxy, protože by prohlížeč komunikoval přímo s cílovým zařízením.
-
Budu stručný, třeba někomu pomůže https://nginxproxymanager.com/
Řeší takové ty základní věci ohledně reverzní proxy na NGINX, ale s jednoduchým web rozhraním a s podporu Lets Encrypt.
-
Reverzní proxy nechá třeba u LE nebo ZeroSSL vystavit certifikát třeba na tiskarna.example.com, bude terminovat HTTPS provoz pro tuhle adresu a bude ho přeposílat na skutečnou tiskárnu protokolem HTTP nebo HTTPS se selfsigned certifikátem.
Po třetí opakuji, že vlastní CA nechci.
-
Reverzní proxy nechá třeba u LE nebo ZeroSSL vystavit certifikát třeba na tiskarna.example.com, bude terminovat HTTPS provoz pro tuhle adresu a bude ho přeposílat na skutečnou tiskárnu protokolem HTTP nebo HTTPS se selfsigned certifikátem.
Po třetí opakuji, že vlastní CA nechci.
Kde vidíš že ti Filip Jirsák navrhuje vlastní CA?
Jinak pokud zařízení umí HTTPS a jenom si neumí požádat o certifikát skrz LE, tak bych udělal tu reverzní proxy (nebo vlastně obyčejný web server kde se publikuje challenge) jenom směrem ven do LE za účelem získání certifikátu a ten bych pak na zařízení nahrál.
Další možnost je neřešit tenhle „split-horizon“ (zařízení dovnitř, LE agent směrem ven) a zkusit jejich DNS challenge -- stačí k tomu tiskarna.example.com přidat TXT/CNAME (nikdy jsem to ale osobně nedělal).
-
Kde vidíš že ti Filip Jirsák navrhuje vlastní CA?
Radí mi, že mám pro spojení mezi proxy a tiskárnou použít self-signed.
Další možnost je neřešit tenhle „split-horizon“ (zařízení dovnitř, LE agent směrem ven) a zkusit jejich DNS challenge -- stačí k tomu tiskarna.example.com přidat TXT/CNAME (nikdy jsem to ale osobně nedělal).
Přesně to jsem si chtěl ujasnit, jestli mám správnou myšlenku.
-
Radí mi, že mám pro spojení mezi proxy a tiskárnou použít self-signed.
Self-signed certifikat je podpisany privatnym klucom samotneho certifikatu, pre jeho vytvorenie sa nepouzije ziadna CA.
-
Že se pro vytvoření self-signed certifikátu nepoužije žádná CA jste někde četl nebo si to jen myslíte? Kdo tedy vytvořil kořenový (a tudíž i self-signed) certifikát ISRG Root X1, který používá Let's Encrypt?
Certifikační autorita je entita, která vystavuje certifikáty. Když si generuji vlastní certifikáty, tak jsem sám sobě certifikační autoritou a je úplně jedno, jestli pro koncová zařízení generuji self-signed certifikáty a nebo mám nějaký kořenový certifikátm, kterým pak teprve podepisuji CSR od koncových zařízení.
Nebo co podle vás znamená "vlastní CA"?
-
Že se pro vytvoření self-signed certifikátu nepoužije žádná CA jste někde četl nebo si to jen myslíte? Kdo tedy vytvořil kořenový (a tudíž i self-signed) certifikát ISRG Root X1, který používá Let's Encrypt?
Certifikační autorita je entita, která vystavuje certifikáty. Když si generuji vlastní certifikáty, tak jsem sám sobě certifikační autoritou a je úplně jedno, jestli pro koncová zařízení generuji self-signed certifikáty a nebo mám nějaký kořenový certifikátm, kterým pak teprve podepisuji CSR od koncových zařízení.
Nebo co podle vás znamená "vlastní CA"?
Self-signed je certifikát podepsaný „sám sebou“, podepisuje ho privátní klíč příslušný k veřejnému klíči, ke kterému je ten certifikát vystaven. Tj. nevystupuje tam žádná certifikační autorita, sám si vytvoříte dvojici klíčů a z ní si pak sám vytvoříte certifikát.
ISRG Root X1 vytvořil Let's Encrypt, ale ne z titulu toho, že jsou certifikační autorita. Vytvořili ho stejně, jako si ho můžete vytvořit vy, akorát pak řekli, že tenhle certifikát budou používat jako kořenový certifikát certifikační autority.
„Vlastní CA“ znamená, že si vytvoříte vlastní kořenový certifikát certifikační autority, z něj si volitelně vystavíte intermediate certifikáty CA a koncové certifikáty podepisujete certifikátem/certifikáty té certifikační autority. Tam, kde se má těm certifikátům důvěřovat, se pak zaregistrují ty certifikáty CA a nemusíte tam registrovat každý z těch self-signed certifikátů zvlášť.
Certifikační autorita není entita, která vystavuje certifikáty. Je to entita, která podepisuje certifikáty svým vlastním privátním klíčem. A self-signed certifikát není podepsán žádnou CA.
-
Další možnost je neřešit tenhle „split-horizon“ (zařízení dovnitř, LE agent směrem ven) a zkusit jejich DNS challenge -- stačí k tomu tiskarna.example.com přidat TXT/CNAME (nikdy jsem to ale osobně nedělal).
Už několikrát zmiňovaný Caddy (https://caddyserver.com) umí žádat o certifikáty LE i s ověřením dns01. Umí se napojit na různé cloudové DNS providery a vytváří tam příslušný DNS záznam. (Pak se umí napojit na nějaké starší řešení, které podporuje spoustu dalších DNS providerů, a nebo si můžete implementovat vlastní napojení.) Takhle to máme pro jeden systém udělané – je vytvořena veřejná doména, hostovaná je u Cloudflare, certifikáty vystavuje Caddy přes dns01 a ten je dostupný jenom z interní sítě a servíruje statické weby a dělá reverzní proxy pro různé další aplikace. Aktuálně tam máme vše přes HTTPS, takže to jde vše přes Caddy a nebylo potřeba řešit delegování vydávání certifikátů pro jiné služby.
-
Jen pripomenu moznost fasovat a obnovovat certifikaty jednoduse s minimalni jednorazovou akci u sebe kvuli challenge.
https://www.root.cz/clanky/nastroj-acme-dns-pohodlne-ziskavani-certifikatu-pomoci-dns/
-
Tak to je teda gól, certifikační autorita si podle pana Jirsáka nevydává svoje vlastní kořenové certifikáty. Kdybyste se alespoň na ten jejich kořenový certifikát podíval, tak byste tam viděl, že Issuer je Internet Security Research Group, tedy Let's Encrypt. Stejně tak to má třeba DigiCert (Issuer: CN=DigiCert Global Root CA, zde máte dokonce Root CA v názvu)...
„Vlastní CA“ znamená, že si vytvoříte vlastní kořenový certifikát certifikační autority, z něj si volitelně vystavíte intermediate certifikáty CA a koncové certifikáty podepisujete certifikátem/certifikáty té certifikační autority. Tam, kde se má těm certifikátům důvěřovat, se pak zaregistrují ty certifikáty CA a nemusíte tam registrovat každý z těch self-signed certifikátů zvlášť.
Upravujete si realitu, aby seděla k vašim argumentům.
Certifikační autorita není entita, která vystavuje certifikáty. Je to entita, která podepisuje certifikáty svým vlastním privátním klíčem. A self-signed certifikát není podepsán žádnou CA.
Když už, tak certifikační autorita nepodepisuje certifikáty, ale na základě CSR (Certificate Signing Request) nebo obdobné žádosti vystavuje NOVÝ certifikát. Z CSR si bere pouze veřejný klíč a zbytek obvykle ignoruje. Ostatní informace pak do certifikátu doplňuje dle sebe a dle toho, co uvedete v nějakém doplňkovém formuláři.
-
Filip má pravdu. Pointa je v tom, že CA existuje tam, kde existuje hierarchie veřejných klíčů, nazvaná PKI. Pokud žádnou takovou infrastrukturu neprovozujete, nemáte ani CA. V tom případě máte jen self-signed certifikát. Ten nemá žádného ověřitelného vydavatele, ale zase se snadno vyrobí jedním příkazem a v uzavřeném prostředí může stačit.
-
Že se pro vytvoření self-signed certifikátu nepoužije žádná CA jste někde četl nebo si to jen myslíte? Kdo tedy vytvořil kořenový (a tudíž i self-signed) certifikát ISRG Root X1, který používá Let's Encrypt?
Certifikační autorita je entita, která vystavuje certifikáty. Když si generuji vlastní certifikáty, tak jsem sám sobě certifikační autoritou a je úplně jedno, jestli pro koncová zařízení generuji self-signed certifikáty a nebo mám nějaký kořenový certifikátm, kterým pak teprve podepisuji CSR od koncových zařízení.
Nebo co podle vás znamená "vlastní CA"?
Ok, vytvorime si self signed certifikat:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -keyout example.key -out example.crt -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.net"
Aka CA sa podla vas pouzije pri vytvoreni?
-
Tak to je teda gól, certifikační autorita si podle pana Jirsáka nevydává svoje vlastní kořenové certifikáty. Kdybyste se alespoň na ten jejich kořenový certifikát podíval, tak byste tam viděl, že Issuer je Internet Security Research Group, tedy Let's Encrypt. Stejně tak to má třeba DigiCert (Issuer: CN=DigiCert Global Root CA, zde máte dokonce Root CA v názvu)...
Vše X.509 certifikáty se dají rozdělit do dvou disjunktních skupin – certifikáty podepsané certifikační autoritou a self-signed certifikáty. To označení „self-signed certifikát“ vzniklo právě proto, aby existovalo jednoduché označení pro „certifikát nepodepsaný certifikační autoritou“.
Kořenový certifikát certifikační autority logicky nemůže být podepsaný certifikační autoritou, protože v době, kdy ten certifikát vzniká, neexistuje ještě ten certifikát certifikační autority (protože právě vzniká).
Možná vás mate to, že certifikační autoritu považujete za nějakou instituci. Ve skutečnosti se pojmem „certifikační autorita“ v tomhle kontextu myslí konkrétní certifikát (nebo certifikáty), jejichž veřejné klíče jsou někým považovány za veřejné klíče důvěryhodné certifikační autority. Protože třeba Let's Encrypt si může vydat kolik certifikátů chce, ale jako certifikační autorita vydává jenom ty certifikáty, které jsou (třeba zprostředkovaně) podepsané buď čtyřkilovým RSA klíčem LE začínajícím na 00:ad:e8:24:73:f4:14:37:f3:9b:9e:2b:57:28:1c nebo 384bitovým EC klíčem LE začínajícím na 04:cd:9b:d5:9f:80:83:0a:ec:09:4a:f3:16:4a:3e.
V položce Issuer self-signed certifikátu jsou jen zkopírované položky ze Subject toho certifikátu – právě proto, že je self-signed, je tedy podepsaný sám sebou, tedy vydavatel je ten samý jako držitel certifikátu. Ovšem ten text nevypovídá vůbec o ničem, self-signed certifikátů, které budou mít v Issuer uvedeno „Internet Security Research Group“, vám klidně vyrobím sto. A dalších sto certifikátů může mít jako Issuer uvedeno „Root CA of Root CA of Root CA“, a stejně to nebude znamenat, že je to ten nejkořenovější kořenový certifikát na světě.
Upravujete si realitu, aby seděla k vašim argumentům.
Nikoli, popisuju realitu tak, jak se to doopravdy používá. Jaký je rozdíl mezi vlastní CA a self-signed certifikáty si dobře uvědomíte, až byste těch self-signed certifikátů vyrobil 150 a těch 150 certifikátů byste musel instalovat na všechna zařízení, která jim mají důvěřovat. A každý týden by vznikaly další self-signed certifikáty a vy byste je musel pořád distribuovat a instalovat. Pak by vám asi došlo, že jste měl raději vytvořit jednu certifikační autoritu, jejíž certifikát nainstalujete jednou.
Když už, tak certifikační autorita nepodepisuje certifikáty, ale na základě CSR (Certificate Signing Request) nebo obdobné žádosti vystavuje NOVÝ certifikát. Z CSR si bere pouze veřejný klíč a zbytek obvykle ignoruje. Ostatní informace pak do certifikátu doplňuje dle sebe a dle toho, co uvedete v nějakém doplňkovém formuláři.
Certifikační autorita podepisuje certifikáty. Technicky není CSR vůbec potřeba, když si budete provozovat vlastní CA, klidně můžete certifikáty vydávat jen na základě dodaného veřejného klíče, nebo dokonce můžete klíčovou dvojici vyrobit sám a předat držiteli certifikátu jeho certifikát i s privátním klíčem. Z hlediska bezpečnosti to není dobré, ale technicky to jde.
Důležitý je ale právě ten podpis autority na certifikátu, kterým autorita stvrzuje, že údaje na certifikátu jsou pravdivé. Podpis zároveň zajistí neměnnost těch údajů (abyste jim opravdu mohl věřit), a díky podpisu můžete hledat, zda ten certifikát podepsala nějaká autorita, které důvěřujete. Tím, že je vše standardizované, dá se to algoritmizovat – takže dodáte seznam certifikátů certifikačních autorit, kterým důvěřujete, dodáte ověřovaný certifikát a případně s ním dodané mezilehlé certifikáty, a algoritmus rozhodne, zda ten dodaný certifikát byl podepsán (i zprostředkovaně) autoritou, které důvěřujete.
-
Tak to je teda gól, certifikační autorita si podle pana Jirsáka nevydává svoje vlastní kořenové certifikáty. Kdybyste se alespoň na ten jejich kořenový certifikát podíval, tak byste tam viděl, že Issuer je Internet Security Research Group, tedy Let's Encrypt. Stejně tak to má třeba DigiCert (Issuer: CN=DigiCert Global Root CA, zde máte dokonce Root CA v názvu)...
Je uplne sumak ako sa nazve certifikat, k tomu aby bol platny CA certifikat, ci uz korenovy alebo medzilahly, tak musi mat nastavene rozsirenia:
basicConstraints=critical,CA:TRUE
keyUsage=critical,keyCertSign, cRLSign
Dalej aby bol ako CA certifikat uznany za platny, musi byt zaradeny medzi znamimi autoritami systemu (alebo browseru, ak ten nepouziva systemove ulozisko).
Kdezto certifikat pre web server bude mat nastavene:
keyUsage=critical,digitalSignature, keyEncipherment
K tomu aby bol uznany za platny, ak je self-signed, staci aby bol zaradeny medzi platnymi certifikatmi systemu (alebo browseru).
-
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?
-
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?
To, co jste popsal, odpovídá tomu, když si Let's Encrypt vystaví certifikát třeba pro svůj web letsencrypt.org – a když se podíváte, opravdu je certifikát certifikát s předmětem CN = lencr.org, který má v SAN i letsencrypt.org, vydaný (zprostředkovaně) autoritou LE, tj. ověřovací cesta vede až k ISRG Root X1. To je ale jiný certifikát, můžete si porovnat jejich veřejné klíče. Existují tedy dva certifikáty (ve skutečnosti jich je podstatně víc), jeden je certifikát certifikační autority Let's Encrypt (který je self-signed, ale zároveň ke stejnému klíči existuje křížově podepsaný certifikát od „Digital Signature Trust Co.“, ale to radši neřešte), druhý je certifikát webu letsencrypt.org, který je shodou okolností podepsaný certifikační autoritou Let's Encrypt.
Když to popíšeme na tom vašem příkladu, bavíme se o situaci, kdy Franta ještě není předseda. Může si klidně sám sobě podepsat papír, že je předseda a může podepisovat průkazky, ale ten papír nebude mít žádnou váhu, nikdo mu nebude věřit. Teprve když to odhlasují Pepa a Lojza, začnou mu oni dva věřit, že je opravdu předseda a budou věřit jím podepsaným průkazkám. To je jako když si vyrobíte svou soukromou CA. A teprve až se ten zápis, že Frantu zvolili předsedou, objeví ve veřejném rejstříku, začnou tomu věřit i ostatní a začnou uznávat průkazky podepsané Frantou.
A proti tomu stojí situace, když si budete vydávat self-signed certifikáty. To je jako kdyby si Franta podepsal průkazku sám a oběhl všechny okolo, že tohle je platná průkazka a mají jí věřit. Pak si Pepa podepíše sám svou průkazku a zase oběhne všechny okolo, že mají té průkazce věřit. A pak si podepíše svou průkazku i Lojza, a zase oběhne všechny okolo, že mají té průkazce věřit.
Pokud vás problematika certifikátů a PKI (public key infrastructure) zajímá, doporučuju např. knížku Velký průvodce protokoly TCP/IP: Bezpečnost. Na Rootu na ní kdysi vyšla recenze: recenze (https://www.root.cz/clanky/velky-pruvodce-protokoly-tcp-ip-bezpecnost/). Sice je starší, ale tam popsané principy jsou stále platné.
-
A teprve až se ten zápis, že Frantu zvolili předsedou, objeví ve veřejném rejstříku, začnou tomu věřit i ostatní a začnou uznávat průkazky podepsané Frantou.
Zapomněl jsem napsat, že tohle odpovídá situaci, když se certifikát certifikační autority dostane na seznamy všeobecně uznávaných certifikačních autorit.
-
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?
změnil jsi definiční obor, tvoje přirovnání je špatně. Důležité je, co podepisuje, self-sign podepisuje sebe svým podpisem a pak tenhle dokument přikládá ke každému dalšímu podpisu.
Proč neuznáš, že se pleteš a píšeš tady nesmysly?
-
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?
Certifikat ale nie je clensky preukaz. Primarnym ucelom certifikatu je overit ze podpisovatel ma vo vlastnictve privatny kluc ktorym podpisuje. To aby certifikat overoval identitu konkretneho subjektu nie je nutne, iba je mozne k do certifikatu tieto udaje vlozit.
Primarny obsah certifikatu je verejny kluc, aby bolo mozne overit podpis vytvoreny privatnym klucom, ktory tvori par s uverejnenym klucom. Dalsia nutna vec ktoru musi obsahovat je sposob pouzitia privatneho kluca. V zavislosti na sposobe pouzitia su povinne dalsie udaje, ktore su ale pre samotny princip fungovania certifikatu irelevantne. A nakoniec je cela tato datova struktura podpisana. Moze byt podpisana vlastnym privatnym klucom (self-signed) alebo klucom nejakej autority. Ci je ten ktory podpis validny sa rozhodne na zaklade zoznamu validnych privatnych klucov, ktory je reprezentovany certifikatmi k tymto klucom.
Ak to chcete vysvetlit na takto stupidnom priklade, tak ten priklad musite dat do kontextu (integracia v skolstve bol fakt blby napad). Cize aby vas priklad bol pouzitelny, tak by sme museli predpokladat ze kazdy uzivatel podpisuje perom s unikatnym atramentom. Pritom nemusi vlasnit len jeden atrament. Certifikat potom obsahuje vzorku podla ktorej je mozne jednoznacne identifikovat atrament. To ze moze obsahovat naviac identifikacne udaje vlastnika atramentu nie je podmienka. Takze Franta(nemusi to byt nutne Franta, moze delegovat na niekoho ineho) podpise vzorky atramentu na preukazkach atramentom urcenym len k tomuto ucelu, vratane tej svojej. Takto vytvorene preukazy ale primarne overuju pravost atramentu, ak overuju sucastne identitu vlastnika atramentu, tak je to udaj naviac.
-
A k povodnemu dotazu:
Problem dnes je rozsirenost Let's Encrypt a jeho certifikatov s kratkou zivotnostou, kedy nestaci raz za rok, dva.. manualne nahodit novy certifikat co je 5 minutova robota. Nie, dnes sa musi investovat cas a peniaze do vyvoja automatizovaneho riesenia ktore musi riesit challenge, uschovu, reload certifikatov a v spranvom case cely proces opakovat.
To automatizovane riesenie nie je nutne znova vyvijat. Mozete pouzit napr. certbot. Pripadne ine riesenie, ktorych je internet uz plny. Alebo mozete ist starou cestou a vynalozit radovo viac zdrojov na certifikat od nejakej CA.
Ak si vezmem ze 99% pripadov je http challenge, tak nie je mozne vypnut port 80, cize aplikacia musi bezat na dvoch portoch a odlisit ci ide o LE na http a podla toho presmerovat na https verziu alebo spracovat LE challenge.
Vypinat 80 port nie je najstastnejsi napad, je dobre tam dat aspom redirect na port 443. K tomu do aplikacie siahat nemusite, da sa to osetrit uz na urovni http serveru.
Dalsie riesenie je skryt aplikaciu za vlastnu lokalnu proxinu(traefik, nginx, haproxy..), takze aplikacia sa odbremeni od https a dvoch spojeni, co je super, lenze zase ta proxy treaz musi routovat 99.99999% dat na prazdno, a zrat hw, len kvoli LE ktore pride raz tri mesiace. Ale zase to riesi sama uz, takze aplikacia samotna sa o nic starat nemusi. Ale zase na produkcii to prinasa dalsiu starost - namiesto jednej binarky a jej konfiguracie je vyzadovana dalsia binarka pre tuto proxinu a konfiguracia pre nu a dodatocne znalosti pre spavnu konfiguraciu a prevadzku.
Toto ma zmysel len v niektorych pripadoch.
- Koli vykonu potrebujete skalovat a tym padom to uz mate rozbehane
- Aplikacia je black box a povodny vyvojar nezvestny
- Aplikacia je tak sprasena ze ina moznost nie je
Tretia moznost je pouzit externu proxinu typu CloudFlare ktora kompletne odbremeni od riesenia HTTPS za cenu ze prevadzka zo serveru na cloudflare je nesifrovana(prakticky mitm) a teda cloudflare ma plny pristup k datam uzivatelov a taktiez pod kontrolou komplet cele DNS. A ked sa rozhodne ze sa im nepacite, tak vas vypnu a mate mozno aj niekolko-hodinovy vypadok. Takze taktiez nie idealna situacia.
Preco by mal byt nesifrovany? Ked sa snazite ohnut sluzbu ktora je urcena k niecomu inemu, tak musite ratat aj s rovnakom na ohybak...
Preto ma zaujima co dnes fici ako najpouzivanejsi postup?
Aplikacia o https nic vediet nemusi. K tomuto je urceny http server. Location http serveru je smerovana na adresar kde si certbot vytvara challenge. Aplikacia o tejto location nema mat ani len tusenie. Ak pouzivate hosting tretej strany, tak je samozrejme ze toto nastavenie dostanete default. Ak si server spravujete sam, tak by ste to mal zvladnut, je to jedna z tych trivialnejsich zalezitosti ohladne bezpecnej spravy serveru.
-
Co je dnes "mainstream" sposob nasadenia https na webove aplikacie?
Problem dnes je rozsirenost Let's Encrypt a jeho certifikatov s kratkou zivotnostou, kedy nestaci raz za rok, dva.. manualne nahodit novy certifikat co je 5 minutova robota. Nie, dnes sa musi investovat cas a peniaze do vyvoja automatizovaneho riesenia ktore musi riesit challenge, uschovu, reload certifikatov a v spranvom case cely proces opakovat.
Ak si vezmem ze 99% pripadov je http challenge, tak nie je mozne vypnut port 80, cize aplikacia musi bezat na dvoch portoch a odlisit ci ide o LE na http a podla toho presmerovat na https verziu alebo spracovat LE challenge.
https://hub.docker.com/u/nginxproxy
Backend pak bezi na jedinem portu (jakemkoliv) pochopitelne. Bezudrzbove, staci jedno repo a v nem jednoduchy docker-compose.yml