Příspěvky

301

Server / Re:Provoz po HTTPS v produkci

« kdy: 15. 12. 2022, 09:22:59 »

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 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.

302

Server / Re:Provoz po HTTPS v produkci

« kdy: 15. 12. 2022, 09:16:53 »

Ž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.

303

Server / Re:Provoz po HTTPS v produkci

« kdy: 14. 12. 2022, 17:52:57 »

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.

304

Server / Re:Provoz po HTTPS v produkci

« kdy: 14. 12. 2022, 15:51:00 »

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.

305

Server / Re:Provoz po HTTPS v produkci

« kdy: 14. 12. 2022, 12:30:16 »

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í.

306

Server / Re:Provoz po HTTPS v produkci

« kdy: 14. 12. 2022, 12:06:37 »

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).

307

Vývoj / Re:Ako na notifikacie mobilneho klienta z webu?

« kdy: 13. 12. 2022, 10:02:57 »

Ale ano, to je notification api, lenze aby to robilo co ma tak je treba push api(= server posle klientovi info a z toho sa potom spravi notifikacia) + service worker, ktory so serverom komunikuje aj ked uzivatel nema otvorenu stranku. ide len o to ako to pozliepat dokopy, na to som sa pytal.

K tomu, co chcete, potřebujete dvě věci – Push API a Notification API. Dohromady se tomu říká Web Notifiactions.

No a WIFT pravděpodobně reagoval na poznámku, že technologie Push API není v Safari ještě dostupná (resp. je pod vývojářským flagem). Jenže to, co ukázal, je Notification API. Takže ano, notifikace na Safari zobrazit můžete, ale jenom z otevřené stránky. Vy jste ale chtěl posílat notifikace i v případě, kdy uživatel vůbec nemá otevřený prohlížeč, k čemuž potřebujete Push API, které v Safari ještě není veřejně dostupné.

308

Vývoj / Re:Ako na notifikacie mobilneho klienta z webu?

« kdy: 13. 12. 2022, 08:30:31 »

Jen zvídavá otázka: bavíte se tu o té věci, která se v češtině v prohlížeči jmenuje "Oznámení" a ve výchozím nastavení má „nejprve se zeptat“?

Ne.

309

Sítě / Re:atribut "d" v DKIM záznamu - vazba nikam nevede?

« kdy: 10. 12. 2022, 13:56:23 »

txt : "s"._domainkey."d"
Nerozporuju možnost volby první část " s", ale druhé "d", že není pevná ve tvaru selector._domainkey.domenavzatazFrom:.com,

d je doména toho, kdo e-mail podepisuje. To nemusí být ten, kdo je ve From. Třeba když poštovní konference přeposílá e-mail, ve From je ten, kdo zprávu poslal, ale e-mail musí podepsat provozovatel poštovní konference.

310

Sítě / Re:atribut "d" v DKIM záznamu - vazba nikam nevede?

« kdy: 10. 12. 2022, 11:05:07 »

Je nějaký rozmuný důvod, proč tenhle tam vůbec je a nebere se hodnota  pevně odněkud?

Protože pro jednu doménu může být víc odesílajících klientů a každý může mít svůj klíč.

311

Sítě / Re:správné rozuzlení CNAME

« kdy: 09. 12. 2022, 15:34:05 »

No a já právě myslel, jestli je přípustné, aby forwardující resolver  při dotazu typu TXT na některý z aliasů vrátil holou odpověď typu CNAME  bez TXT (tedy výstup příkazu host  jen jednořádkové "dotazovane jmeno" is an  alias for "original")

To je každé něco jiného. Resolver (systémová knihovna) vrací jen hodnotu požadovaného záznamu (rekurzivní dotazování zajistí sám). host vrací detailnější informace a ptá se na ně konkrétními dotazy, není to jen prosté zavolání systémového resolveru (rekurzivní volání si zajistí sama utilita host).

312

Vývoj / Re:Ako na notifikacie mobilneho klienta z webu?

« kdy: 09. 12. 2022, 14:09:27 »

Ano, Push API a Notification API jsou ty správné technologie. Akorát to ještě nepodporuje applovské Safari – je to tam schované pod developer flagem, takže se to dá zapnout, ale ve výchozím nastavení to není zapnuté. Očekávalo se, že to bude zpřístupněno letos na jaře, ale nestalo se tak.

Doporučuji začít zde: https://caniuse.com/push-api Na záložce Resources najdete odkazy na specifikaci a dokumentaci, včetně příkladů serverového řešení.

313

Sítě / Re:správné rozuzlení CNAME

« kdy: 08. 12. 2022, 23:16:14 »

host -ttxt zive.cz ; host -ttxt www.zive.cz (nepoužil jsem autoritativní server)

Ale www.zive.cz je alias pro zive.cz. Takže ta odpověď, kterou dostanete, je právě výsledek rekurzivního dotazu na zive.cz po té, co resolver zjistil, že www.zive.cz je alias pro zive.cz.

To jsem si myslel, že je nemá mít. Ale otázka je jestli se tím myslí že nemají být v záznamech v zóně a nebo zda je ani  nemá vracet (nějaký cizí )resolver

Když nejsou v zóně, nemůže je vracet ani resolver. Resolver si nemá vymýšlet neexistující záznamy.

314

Sítě / Re:správné rozuzlení CNAME

« kdy: 08. 12. 2022, 22:30:07 »

Zajímá mě ale jedna věc, a sice jaké druhy odpovědí se vrací na druhy dotazů na nějakém resolveru.
CNAME vrací CNAME
A vrací CNAME+A
nespecifikováno cname,a,mx
Je to nějaká dobrá vůle  resolveru, že to pospojuje?

Když se ptáte na konkrétní typ záznamu, vrací resolver daný typ. Když se ptáte bez typu, vrací všechny záznamy s daným jménem, bez ohledu na typ. Když jako odpověď dostane CNAME, vezme kanonické jméno z odpovědi a zeptá se znovu na něj a typ, který jste požadoval. Případně se to opakuje, pokud zase dostane CNAME odpověď (což by neměl, ale musí s tím počítat). Výjimkou je, když požadujete CNAME, ten se vrací rovnou (to rekurzivní hledání by v takovém případě nedávalo smysl).

Ale setkávám se s chováním, že domény které mají CNAME záznam na jinou doménu už jiné záznamy nemají

Tak je CNAME definováno – pokud je k nějakému jménu definován záznam CNAME, žádné jiné typy už k tomu jménu nemají být (kromě typů pro DNSSEC, jinak by to nefungovalo).

Ale v některých případech TXT záznam má i alias.

Myslíte, že k jednomu jménu existuje CNAME záznam i TXT záznam? To je špatně. Jste si tím jistý, že dostáváte opravdu TXT záznam k tomu jménu, že to není záznam až z cílového jména (z kanonického jména)?

Co z toho je správně, může mít i alias své  záznamy

Ne, nemá je mít. RFC 1034, 3.6.2.

315

Sítě / Re:Neshoda reverzních záznamů u odesílajícího SMTP

« kdy: 08. 12. 2022, 22:19:43 »

Musím uznat, že death walker nepoužívá uplně korektní pojmenování, kanonické jméno slyším prvně a je to takové hospodské vyjadřování.

Ve skutečnosti je to termín z RFC zabývajících se doménovými jmény…

Tu se kanonické jméno použije pro řetězec v HELO, jindy se tím myslí název domény.

Je to (doménový) název počítače. Který se má dávat do EHLO.

Prostě je to ten název, jak mají počítač pojmenovaný administrátoři. Dnes jsou servery očíslované, nebo mají nějaké generovaná ID, protože jich je spousta a pořád se mění. Ale dříve měl administrátor pár serverů a ty nějak pojmenovával. Podle planet, postav z nějakého seriálu, pivovarů, měst, řeckými písmeny abecedy… Takže firma měla třeba servery porthos.example.net, athos.example.net a aramis.example.net. To byla jejich kanonická jména, na které měl vést PTR záznam jejich IP adresy (a existoval pro ně samozřejmě A záznam). No a na Porthosu běžel třeba souborový server a databáze, tak na jeho IP adresu směrovaly třeba názvy samba.example.net a db.example.net, Athos zajišťoval třeba web a e-mail, takže na něj směřovalo www.example.net, smtp.example.net, pop3.example.net a mail.exmaple.net, pokud měli i webmail. MX záznam s nejvyšší prioritou (nejmenším číslem) směřoval na smtp.example.net, záznam s nižší prioritou pak na server ISP. No a všechny tyhle názvy jako samba.example.net nebo smtp.example.net už jsou doplňující názvy, nejsou to kanonické názvy serveru.