Vlákno názorů k článku Certifikáty prakticky s utilitou OpenSSL: formáty, prohlížení, převody a testování od czechsys - Strasne bych rad videl implementaci let's encrypt nekde,...

Uniká mi architektura systému, který řešíte. Není to HTTPS, kde byste na loadbalancerech dělal terminaci TLS a rozvažování zátěže. Řešíte to pro stovky serverů, ale nemáte automatizovanou jejich konfiguraci. Pro jedno doménové jméno dáváte certifikát na X serverů – ani nevíme, zda jsou to servery stejné služby, nebo jsou to různé služby. Do toho nasazujete aplikace přímo z gitu.

Připadá mi, že máte N různých způsobů použití, každý řešíte jinak s jinou mírou automatizace, a na to se snažíte napasovat nějaký jeden univerzální systém pro výměnu certifikátů.

V uvazovanem pripade je to primarne https webova sluzba.

Provozujeme sluzbu somedomain.tld. Ta je terminovana na nekolika L7 balancerech (x serveru, kde se nahrava certifikat). Nasledne je dany certifikat nahrany i na web backendech (Y serveru) - spojeni mezi balancerem a web serverem je zasadne sifrovane.

Tyto servery se konfiguruji pres ansible, pricemz git je pouzit primarne jako dokumentace zmen. Nemame Tower, ani jiny automaticky CI/CD, takze zmeny se volaji manualne - zmen u nas neni tolik. Jenze u let's encrypt uz z principu manualni volani zmen je nepouzitelne.

A do toho by se hodilo pouzivat let's encrypt. Kdyz nasadim nejakeho centralniho bota, tak ten bot nebude mit seznam serveru, ani ansible to nevi, kde ty certifikaty jsou, dokud nenacte konfiguraci tech balanceru/web serveru. Takze se pak bavime klidne o spusteni konfigurace na stovkach serveru (i kdyz zmena bude jen na X+Y).

Pak je potřeba řešit ty L7 balancery. Záleží na tom, co je to zač – třeba Caddy má podporu pro ACME vestavěnou, pro nginx nebo HAproxy se dá použít jedna z mnoha implementací ACME klienta. Pokud je to nějaké HW řešení, F5 apod., potřebujete ty certifikáty obnovovat nějakým skriptem z venku (zase stačí si vybrat z výše odkázaného seznamu) a pak je jen do zařízení nahrát. Doporučuju v takovém případě používat validaci přes DNS – nepotřebujete pak žádnou spolupráci toho balanceru, tomu jen dáte hotový certifikát.

Osobně bych v takovém případě nedistribuoval jeden certifikát na všechny balancery, ale (pokud nemáte těch balancerů desítky a vejdete se do limitů LE) měl bych na každém balanceru samostatný certifikát s vzájemně posunutým datem vydání. Ať vám nekončí platnost všech certifikátů najednou, ale je to pěkně rozdistribuované. Ono se to sice obnovuje automaticky, takže by to mělo být jedno, ale jistota je jistota, k chybě může dojít i u vás i na straně LE.

Dále tam máte ty backend servery. Pokud na nich neodkážete výměnu certifikátů snadno zautomatizovat, dejte tam selfsigned certifikáty nebo certifikáty z vlastní autority s platností několik let. (Bacha na to, že jak se před pár měsíci přesvědčili ve Flexibee, deset let je už dost dlouhá doba na to, aby se zapomnělo, že vůbec někde takový certifikát je.) Loadbalancerům je to jedno, ty nepotřebují na straně backendu všeobecně uznávané certifikáty – nastavíte tam buď svou autoritu nebo ty selfsigned certifikáty.

Na sifrovane spojeni mezi balancery a backendy LE certifikat opravdu nepotrebujete. Na tento ucel muzete klidne pouzit interni CA a klidne certifikaty s delsi platnosti. Takze cely "problem" se razem smrskne na to, jak dostat cerfifikat na par balanceru. A to uz tu popsane mate vyse - realne muze byt kazdy balancer v tomto smeru autonomni.