OK, tak udělám víc certifikátů pro domény neco1.example.net neco2.example.net atd. Ale jak vyřeším server aliasy? V jednom certifikátu mám domény v CN, takže jeden konfig Apache pro všechny domény na konkrétní subdoménu:
<VirtualHost 127.0.0.1:8443>
ServerName mailadmin.example1.net
ServerAlias mailadmin.example2.net
ServerAlias mailadmin.example3.net
ServerAlias mailadmin.example4.net
ServerAlias mailadmin.example5.net
ServerAlias mailadmin.example6.net
ServerAlias mailadmin.example7.net
DocumentRoot /var/www/postfixadmin
ErrorLog /var/log/apache2/error_ssl_mailadmin.log
CustomLog /var/log/apache2/access_ssl_mailadmin.log combined
Options -Indexes
SSLEngine On
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
</VirtualHost>
To butu mít na každou subdoménu a každý alias zvlášť config a certifikát?
Já mám něco podobného. Cestu k certifikátu mám na Debianu v /etc/apache2/ports.conf
Listen 80
<IfModule mod_ssl.c>
Listen 443
SSLCertificateFile "/etc/ssl/certs/https.crt"
SSLCertificateKeyFile "/etc/ssl/private/https.key"
</IfModule>
A chtěl jsem si to zkušebně přidat do jednotlivých (sites-enabled) konfigů virtualhostů doplněním a zakomentováním těch cest k certifikátům v ports.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
...................
SSLEngine On
SSLCertificateFile /etc/ssl/certs/https.crt
SSLCertificateKeyFile /etc/ssl/private/https.key
...................
</VirtualHost>
</IfModule>
Když ale odstraním z ports.conf ty řádky s certifikáty, nefunguje mi ani http? Co tam mám blbě? Díky.
Přesně tak. DNS i VirtualHost ve web serveru je přes hvězdičku, aplikace podle hlavičky Host udělá dotaz do db a vrátí příslušný odkaz.
Bohužel provozuju jeden neziskový projekt, kde SW je takto napsaný a peníze na komerční wildcard certifikát nemáme. Těšil jsem se na Let's Encrypt, ale pro tento use-case je hodně těžko použitelný.
Nevylučuju, že se to někomu stát může, ale ve všech případech, kdy jsem se s takovým řešením setkal v praxi, to bylo na dedikované subdoméně a admini věděli, jak to funguje. Předpokládám, že stejné je to s blog.root.cz, ale i blog.idnes.cz, blog.ihned.cz). Je to celkem běžný usecase a je imho škoda, že tam Let's Encrypt požít nepůjde.
Jirsaku ty ses fakt povedl. Aneb jak politicky jit proti uzivatelum kteri maji sve problemy. Resim uplne stejny problem - mam *.domena.tld kde hvezdicka je username a tech je x desitek tisic. Proste to tak chci a potrebuju. Fakt je to ta tvoje rada nejaka hitparada? Tohle je cely to vase slavny vynuceny https pres mrtvoly. horsi jak grínpis.
Pokud se vám ta rada nelíbí, tak se jí neřiďte.
To je fakt neuvěřitelný. Někdo představí nějakou službu nebo popíše, jak něco dělá, načež se seběhnou místní trollové, j/x/fd, Seti, Lol Phirae a to_je_jedno, a začnou nadávat, že oni takovou službu vůbec nepotřebují, tak jak si někdo může dovolit něco takového nabídnout, jak někdo mohl o něčem takovém vůbec začít přemýšlet. Tak se s tím děcka smiřte, že nejste pupkem světa, že si někdo klidně může dovolit nabídnout službu, kterou vy k ničemu nepotřebujete, že někdo může věci dělat jinak, než vy. Nemusíte pořád všem vnucovat, že váš pohled na svět je jediný správný a tvářit se, že každý, kdo něco dělá jinak, než vy, je přinejmenším úplný debül.
Problém to je snad pouze v případě, že by se to mělo zakládat on-the-fly, tedy že před navštívením https://xyz.blog.root.cz nebylo toto doménové jméno serveru známé. Pro což si nedovedu moc dobře představit use-case.
Pokud ale dojde k uživatelské registraci, pak nevidím problém v tom, aby toto řešil nějaký skript, který se při té příležitosti spustí.
A je to taková zátěž?
(Mimochodem, certifikát se při registraci nebude měnit, ale přidávat…)
A pokud dosáhnete takového množství uživatelů, že to bude významná zátěž pro servery, jistě peníze za wildcard certifikát od jiné CA už budou pouze drobné.
Myslím, že LE prostě řeší velkou část use cases zadarmo. Buďme za to rádi. Že neřeší některé edge cases – no a co? Svoje místo tu má i bez nich a řešení takovýchto edge cases by stálo mnoho sil s malým výsledkem.
Pokud budete mít tolik uživatelů, že to bude generovat významnou zátěž serveru (a pokud nemáte dost velký edge case jako třeba tisíc nových subdomén denně na jednoho uživatele), pak stejně budete muset řešit nějaké financování serverů i bez HTTPS. (Ať už reklama, nebo sponzorské dary.) A ten wildcard certifikát už asi nebude tak velká nákladová položka. Ale pochybuju, že třeba pro root blog by tento postup byl až takový problém.
A jaký vidíte problém s bezpečností?
Mně osobně třeba ani tak nejde o zátěž na serveru (u nás jde jen o pár desítek certifikátů), ale o vytváření zbytečných vazeb napříč infrastrukturou. Do teď stačilo, aby si aplikace přidala záznam do db, se kterou stejně pracuje, ale teď bude muset ještě při zakládání blogu volat externí utilitu a konfigurovat web sever. Samozřejmě, že můžeme říct, že koupit wildcart certifikát není takový náklad (i když pro neziskovku je každá koruna problém), ale myslel jsem, že hlavním přínosem Let's Encrypt má být odbourání paradigmatu bezpečnost = nadstandard za peníze.
Ty vazby podle mne nejsou zbytečné. Naopak díky tomu máte podchycenu vazbu, která reálně existuje, ale kterou dnes stavíte jenom na shodě nějakého textu ve webovém prohlížeči.
To, že dnes konfigurujete web server, je přece jenom takový workaround. Ideální řešení je přece takové, že máte web server napojen na tu databázi (takže hlavičku Host hledá v té databázi), DNS server také, no a žádnou externí utilitu volat nebudete, protože ten přímo v té aplikaci zakládající nový záznam do DB bude i vystavení certifikátu přes ACME a zápis toho certifikátu do databáze (odkud ho bude načítat ten web server).
Jasně, takže překopeme úplně všechno. A kdyby náhodou ta aplikace běžela za load balancerem, který terminuje SSL (třeba AWS ELB) tak to nepůjde vůbec, nebo teoreticky takový LB najdu nebo si napíšu sám a budu v něm udržovat datový model aplikace, kdyby náhodou programátoři potřebovali tu tabulku se seznamem blogů změnit. A kešování přístupu do db budu taky řešit na úrovni web serveru.
To jsou opravdu rady ze života.
Někdo má aplikaci udělanou tak, že nic překopávat nemusí. Pokud vy ji máte udělanou tak, že byste musel úplně všechno překopávat, zvážíte, jestli to pro vás má význam nebo nemá. Mně to rozhodování připadá celkem jednoduché, nevidím důvod, proč o tom v několika komentářích mudrovat v diskusi. Zatímco vy se tváříte, jako by vás k té změně někdo nutil a vám se do toho vůbec nechtělo.
(Mimochodem, certifikát se při registraci nebude měnit, ale přidávat…)
Nikoliv. Řeším Jirsákův genitální nápad, že si pro každou subdoménu přidám SAN do certifikátu. Ten byl vopravdu dobrej.
Tak jistě. A ten certifikát má reálně něčemu sloužit, nebo je pouze k onanování nad tím "Hele, já sem ale borec, mám web s HTTPS, heč!"... Nevím jak vy, ale pokud nějaký web bude měnit 50x denně certifikát, tak usoudím, že to buď někdo hacknul, nebo mám vážný problém s MITM.
Používání různých certifikátů k témuž jménu nikomu neznemožňuje nalezení problému s MiTM. Máte seznam důvěryhodných autorit, pokud některá z nich vydala certifikát, pak věříte tomu, že je certifikát pravý. To, že je obecně známo, že někteří ověřují certifikáty špatně, opravdu neznamená, že je dobrý nápad podporovat to chybné ověřování.
Stále čekám na vysvětlení ohledně toho, je je na wildcard certifikátu špatného. Asi se ho nedočkáme.
Jinak ale samozřejmě podobné retardované využívání certifikátů a jejich neustálé změny to nalezení MITM nesmírně usnadňují a urychlují, to je pochopitelné a je to vidět na příkladech, jako je CNNIC - https://googleonlinesecurity.blogspot.cz/2015/03/maintaining-digital-certificate-security.html