Vlákno názorů k článku Let's Encrypt komerční certifikáty ze státní správy nevytlačil od Jan Mareš - Nasazení Let's Encrypt závisí na provozovaných systémech. Často...

  • Článek je starý, nové názory již nelze přidávat.
  • 27. 2. 2025 8:14

    Jan Mareš

    Nasazení Let's Encrypt závisí na provozovaných systémech. Často se stává, že korporátní aplikace specificky počítají s roční manuální výměnou bez poskytnutí rozumného API. Narazil jsem na to minimálně u Cisco řešení, propojení s Microsoft cloud prostředím (např. ADFS), a řešení využívající Microsoft produkty ať už on-premise nebo interagující s cloudem (např. ADFS). Překvapilo mě, že load-balancer od F5 Networks stále nemá nativní podporu, ale naštěstí poskytuje rozumné API pro integraci.

    Většinou, když se bavím s dodavateli, tak autoritu neznají a s automatizací výměny certifikátů v systémech nepočítají. A je jedno zdali je to velký/malý systém. Tato situace platí už od roku 2016 a vždy nás tlačí do standardního certifikátu. Už se to naštěstí pomalu zlepšuje se zkracováním platnosti certifikátu. Takže v článku uvedeného výčtu systémů bez Let's Encrypt bych to viděl spíše tak, že u většiny je řešení plně pod správou dodavatele, který bude mít na starosti výměnu certifikátu a ten jde cestou minima práce.

    Ve snaze o nasazení pak je nutné do veřejných zakázek explicitně uvádět, že součástí dodávky je i řešení automatizované výměny certifikátů od Let's Encrypt.

    Za mě použití Let's Encrypt není o penězích, ale hlavně snížení zátěže spojené s obsluhou výměny certifikátu. Náklady na všechny veřejné certifikáty v organizaci se bude pohybovat v řádu desetisíců korun za rok, to je v celkovém rozpočtu zanedbatelné. Ale člověk, který má systém na starosti si kromě monitoringu neúspěšné obnovy nemusí hlídat čas obnovy, zajistit vydání nového certifikátu a následně jeho úspěšné nasazení. Opakovaně se nám stalo, že s výměnou certifikátu u některých systému byly problémy (např. u SAPu, ADFS).

    Nasazení bezplatné autority je tak mravenčí práce, kdy se v lepším případě použije jen reverzní proxy s certbotem a v tom horším se doplní o skript manipulující s certifikátem a interagující s více systémy. Takto se nám povedlo zredukovat počet komerčních certifikátů na tři a po nasazení F5 to nejspíše bude jen jeden.

  • 27. 2. 2025 14:45

    Uncaught ReferenceError:

    Ona je možná chyba nasazovat LE certifikáty tam, kde to není z podstaty veřejné. Jednu dobu jsme tady měli také vlnu, že se LE cpal všude, dnes spokojeně jedeme na vlastním CA a tam je potřeba veřejný přístup se strčí brána (reverzní proxy, terminátor), který má LE na jedné straně a na druhé straně validuje interní CA. Jak píšeš, strčit na F5 a necpát nikam interně.

    Pokud jde o SOHO krabičky (routery a podobně), které jsou oddělené a servisují se ručně na místě, tak u nich nefungovaly veřejné certifikáty nikdy. Tam asi asi vhodnější použít api a mít vlastního klienta, agregátor (mobilní apku, endpoint někde v internetu), který komunikaci bude zprostředkovávat.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).