Názory k článku Let's Encrypt nabídne wildcard certifikáty platné pro všechny subdomény
-
MP (neregistrovaný)
At the simplistic level, the client talks to the Let's Encrypt ACME server and obtains a "token" that needs to be placed in a TXT record in your DNS. If your DNS provider has an API then this record can be added automatically, or you can do it manually. Once the TXT record is there, Let's Encrypt verifies this and provides you with a certificate (via the same client).
You will need a new token every time you need to renew for a new certifcate though, hence automation is easier.
-
Filip JirsákStříbrný podporovatelZáleží, čemu říkáte DNS API. Prostě musíte umět změnit obsah TXT záznamu. Pokud DNS spravujete přes zónové soubory, stačí umět změnit ten soubor.
-
Díky. Právě ta změna klíčů v DNS je docela překážka pro snadné a rychlé nastavení. Certbot sám o sobě nic s DNS neumí. A nenašel jsem žádné hotové řešení či návody jak to udělat (mít zónu u sebe mi přijde jako overkill)
A to je DNS tak lákavá cesta - je to myslím jediná možnost pro získání let's encrypt certifikátu pokud vaše služba běží na nestandardním portu.
Osobě jsem službu na nestandardním portu vyřešil synchronizací času cron obnovy let's encryptu se scriptem který mění port forwarding... je to děsné řešení, ale umožňuje použít certbota - trvalo to jen chvilku.
-
j (neregistrovaný)
Nektery registratori na to maji API, ale samo kazdej jiny, takze si ten pripadnej script musis napsat sam. Ale zcela obecne se predpoklada, ze kdo ma domenu ma i DNS a neni to zadnej overkill, je to standardni reseni standardni situace. Opet, nektery registratori umi zcela bezne i to, ze ty si provozujes master a jejich DNS fungujou jako slave, pokud nechces resit vic DNS na ruznych mistech.
-
Muj oblibeny dehydrated umi bez nejakeho programovani tyto DNS providery - https://github.com/lukas2511/dehydrated/wiki/Examples-for-DNS-01-hooks a mozna se daji najit i dalsi. Treba si to tady nejaky registrator precte a napise hooky pro svoje API ;-) Pro subreg nebo wedos by to melo byt tak na jeden den prace. Pripadne muzete pouzit AWS Route 53, ale tam cena hrave prevysi cenu registrace domeny.
-
LE certifikatry jsou zdarma velmi virtualne, protoze jejich sprava je obecne draha. Bezny certifikat je na dva roky, nektere az na pet let a proste ho nasadite a jdete od toho. U LE se musi hlidat platnost, protoze ne kazda automaticka obnova probehne. Sem tam se stane ze vznikne nejaky pokazeny soubor s certifikatem a na to apache umi jen havarovat, ani test konfigurace pred restartem tuhle situaci nevyresi. Dostavat ty certifkaty do javy a ruznych loadbalanceru je celkem bitva.
Na druhou stranu vystavili 100 milionu certifikatu, neco je na ukor stavajich CA, ale evidetne tady je velike mnozstvi lidi, kteri chteji sifrovat a cena certifikatu byla prekazkou. A to ze do toho musi investovat trochu usili je nakonec posune dal, protoze se neco nauci.
-
misho (neregistrovaný)
Ak mi vysvetlis, ako by si pomocou self-signed certifikatu zabezpecil CIA (Cinfidentiality, Integrity, Authenticity), tak ta navrhnem na IT osobnost roka. Co mi brani urobit si self-signed certifikat pre napr. www.ubuntu.com? Budes mu verit? To je to iste, ako keby si si sam robil vlastny obciansky preukaz, lebo ten bude lepsi/krajsi ako ten, ktory ti vyda policia :) Nehovorim, ze je to idealny stav, ale v PKI je proste nieco ako certifikacna autorita alfou a omegou celeho trust chainu a toto self-signed certifikaty nesplnaju. A ak by si to chcel pre osobnu potrebu, tak si urob self-signed a vloz ho do Trusted root certification authorities storu a bude mu verit kazdy prehliadac v tvojom PC (pre doplnenie - musis pouzit store pocitaca a nie uzivatela).
-
j (neregistrovaný)
2misho: co mi brani si nechat vydat certigfikat treabs pro guugla? NIC ... staci mit dost penez, pripadne najit dostatecne deravou CA. Jak ty poznas ze neni spravnej? NIJAK, protoze tupej tvurce tvyho browseru ti tam tu CA dal jako duveryhodnou. A tvymu browseru je uplne uprdele ze jeste pred minutou to melo jinou CA s jinym certifikatem.
Ale sem vazne zvedav, jak mi a dalsi miliarde uzivatelu vnutis nejakej svuj selfsign, kdyz sem si uz nejakej overil a ulozil.
-
ad zóna - overkill: nic Vám nebrání mít ""stealth"" konfiguraci
- registrátora A
- DNS poskytovatele B který poskytuje i možnost nastavení sekundárního DNS serverupostup
- nastavit u registrátora A name server-y na poskytovatele B
- nastavit u poskytovatele B dns/zóny jako sekundární + master je Váš stroj
- na svém stroji nastavit DNS jako master a na firewallu povolit pouze poskytovatele B (z jakých adres se provádí AXFR najdete většinou v dokumentaci - nemusí být stejný jako name server-y!)
- nastavit i v samotné zóně NS na name server-y poskytovatele Bnevýhoda: potenciálně další bod kde se můžou věci pokazit
-
Pokud užíváte name servery registrátora, tak pro automatickou obnovu certifikátu pomocí DNS challenge (dns-01) musí registrátor poskytovat DNS API, nebo, pokud jej neposkytuje, musíte emulovat editaci TXT záznamů přes webové rozhraní registrátora. To sice není ideální řešení, ale např. u Web4U to nebyl velký problém a funguje mi to bez úpravy od počátků Let's Enrypt.
-
Hryzo (neregistrovaný)
Ako riesit problem,ked je nutne robit renew certifikatu a po jeho renew je nutne spravit import verejneho kluca pre vsetkych klientov.Ako to automatizovat? A ako riesit problem ked je nutne robit reimport verejneho kluca medzi viacerymi lets encrypt certifikatmi - tzv. do kriza?
-
Filip JirsákStříbrný podporovatel
Automatizace závisí na tom, co klient umí. Ale nedává mi smysl, proč si necháváte vystavit certifikáty od důvěryhodné autority, a pak je importujete do klientů. Buď bych do klientů naimportoval certifikát autority, pak vás výměny koncových certifikátů nemusí zajímat. A nebo tam chcete mít konkrétní koncový certifikát, a pak zase nepotřebujete certifikát od autority a klidně si tam můžete dát svůj self-signed s platností 10 let.
-
ET (neregistrovaný)
ale zároveň na všechny možné subdomény (zkrátka *.priklad.cz)je to slovickareni, ale wildcard plati vzdy jen pro primo podrizene subdomeny - takze pro
*.*.priklad.czuz cert fungovat nebude (napr. https://www.ssl.com/faqs/can-i-create-a-subdomain-domain-com-wildcard-how-about-subdomain-com/), jestli to davaji do SAN atributu certu a jestli to bude LE podporovat netusim... -
Filip JirsákStříbrný podporovatel
To právě není tak docela pravda, některé programy to mají implementované tak, že hvězdičkový certifikát platí pro jakoukoli subdoménu – takže
*.example.comakceptují i proone.two.example.com. -
Filip JirsákStříbrný podporovatel
Za prvé to nijak nesouvisí s tím, že některé implementace ověřování certifikátů chápou hvězdičku tak, že pokrývá i tečku. Kdyby měl někdo certifikát pro
*.co.uknebo*.com, byl by to pěkný průšvih i jen pro tu jednu úroveň doménových jmen.
Za druhé, prohlížeče používají Public Suffix List nebo nějakou jeho obdobu, takže takové certifikáty by ani neakceptovaly. -
Filip JirsákStříbrný podporovatel
Ono to tak dříve bylo podle standardů. Dříve se tak choval Firefox (kvůli zpětné kompatibilitě), tam už to bylo před pár lety opraveno. Chovalo se tak i cUrl, současný stav nevím.
-
Sten (neregistrovaný)
Kterých standardů? Firefox se tak kdysi choval, ale to byla chyba a bylo to jako chyba vyřešeno. IE ani KHTML (WebKit) se tak nikdy nechoval. SSL ani X.509 wildcardy nikdy nedovolovalo a HTTP over TLS od počátku zakazovalo matchovat víc než jeden label. Takže který standard to umožňoval?
-
Filip JirsákStříbrný podporovatel
Nebyla to chyba, bylo to záměrné chování kvůli zpětné kompatibilitě. Že to bylo podle standardů jsem napsal špatně – před RFC 2818 žádný standard hvězdičku v certifikátu nedefinoval, takže záleželo na každém, jak si to implementoval.
ČLÁNKY DO MAILU