Vlákno názorů k článku Google chce omezit platnost certifikátů na 90 dnů, změna zřejmě přijde brzy od czechsys - No, pokud to projde, tak jsem v prekerni...

No, pokud to projde, tak jsem v prekerni situaci. Ja proste neumim spolehlivou automatizaci na vymenu crt do nasi infrastruktiru naprogramovat, zejmena, pokud dany certifikat pouzivam na vice serverech (redundance).

A temi misty mam na mysli v tuto chvili jen verejne pristupne webove sluzby...

V pripade, ze certifikat je na jednom serveru, tak na to mi ruzne acme utility fungovaly v pohode (overovani pres lokalni klic). Ale propagace (=rekonfigurace ze source of truth) treba wildcard crt vsemoznych sluzeb...jejda jejda.

Myslím, že ten tlak je v tuto chvíli zaměřen právě na to, aby dodavatelé těchto různých enterprise řešení konečně začali ACME podporovat. Ale jsem zvědav na ten termín – protože životnost těchto řešení se počítá v letech (a to spíš pět a více než dva roky), takže i kdyby Fortinet, F5 a další začali ve všech svých produktech podporovat ACME dnes, bude to rozšířené za pět deset let.

Treba fortinet acme podporuje, ale co jsem cetl diskuze, tak to "moc nefunguje". A treba nase aktualni firewally acme nepodporuji.

Ja hlavne mam problem i s tou automatizaci. Pokud je u nas hostovana domena zakaznika, tak nelze provest dns validaci, ale je nutna https validace. To implikuje vytvoreni centralniho bodu, na ktery se nasmeruji veskere verejne body, kterymi ta sluzba muze projit. No a pak to narvat do gitu apod., jinak by konfiguracni sluzby musely sahat do jineho centralniho bodu pro crt. Zejmena chutovka, kdyz ten crt pro novou domenu neexistuje.

Předpokládám, že tam stejně máte nějaké loadbalancery, které mají stejnou konfiguraci. Tak akorát do té konfigurace doplníte, že požadavky na /.well-known/acme-challenge/ má přesměrovávat na server, který vyřizuje vystavení certifikátů, ne? Nebo je tam něco složitějšího?

Třeba Caddy si umí pro certifikát sáhnout do různých úložišť. Ono je dost rozdíl, jestli se ta podpora doimplementovává do něčeho existujícího, nebo se to staví rovnou s tím, že to má podporovat ACME. Zrovna na Caddy serveru je to dobře vidět – ten je HTTPS by default, takže základní konfigurace HTTPS spočívá v tom, že podporu HTTPS nevypnete :-) Což je samozřejmě úplně něco jiného, než když podporu ACME přidáváte nějakou externí utilitou do Nginxu nebo Apache.

Ok, odpovídám si i sám na svůj předchozí příspěvek.

Řešením bude asi všechny tyhle jiné protokoly než https tj. imaps pop3s smtps ldaps a jiné protáhnout taky přes reverzní proxy (u nás centrální nginx teda vlastně OpenResty) jako tzv. stream. Kde acme funguje perfektně.

Akorát to mi furt neřeší DANE a automatizaci updatu DNS záznamů třeba pro SMTP....
Před několika dny mi po výměně certifikátu neproběhla automaticka změna hashe v DNS a to zabolí, protože příchozí pošta je prostě nenávratně ztracena kvůli odmítnutí odeslání ze strany odesílatele. Snad jedině krok zpět a zrušit celé DANE, které stejně tenhle koncept certifikátů nějak odmítá...

Vidím to správně?

Ano, v drtive vetsine tam mam balancery. Ja ten problem rozdeluji na 2 body.

1] ziskani certifikatu - https validace "jednodussi", dns "validace lepsi, ale slozitejsi"
2] propagace certifikatu

A ten bod 2] je ten vetsi problem. Ta sluzba, co v 1] ziskava certifikat, nema tuseni, kde vsude je pouzit. Pokud ma clovek puppet a podobne pull orchestrace, je to jendodussi. Ale v pripade push orchestrace, tam je nutne spustit rekonfiguraci vsech typu sluzeb, ktere jsou verejne. Jinak by to vyzadovalo zase nejakou slozitou programatorinu zjistit, kde je ten crt vlastne nasazeny, aby se rekonfigurace spustily na podmnozine sluzeb. Treba, kdyz konfigurace nejsou v databazi, jak zjistit, kde vsude je ten crt nasazen? No...

Ja bych nejradsi certifikaty zrusil (je s tim cim dal vcetsi oser) a radeji bych se treba tou DANE cestou...