Názory k článku Certifikáty Let's Encrypt se skriptem Dehydrated

Pekny popis ... Pro FreeBSD existuje port https://www.freshports.org/security/dehydrated/ drive se to jmenovalo letsencrypt.sh.

Díky za pěkný článek. Vyzkouším. :)

Certbot je take jedno z pouzitelnych reseni - https://certbot.eff.org/
V debian jessie/backports dostupne i jako balicek.

Certbot je přímo referenční klient od Let's Encrypt. Je to to, co se dříve jmenovalo letsencrypt.

Zdravím, rozumím tomu správně, že s Dehydrated mohu automatizovat let's encrypt certifikáty pro služby které běží na nestandardních portech? To by bylo docela super. Díky

To lze v zásadě s libovolným klientem, protože certifikát je vázaný na doménové jméno, ne na TCP port. Autorita ale vyžaduje v každém případě ověření na 80/443 nebo pomocí DNS. Že se pak certifikát použije třeba v Postfixu nebo na libovolném portu, už je jedno.

Dobrý den

Nemáte někdo zkušenosti s nasazením Let`s Encrypt na RMerlin firmwaru, Entware-ng s lighttpd? Debian, ubuntu,.. repozitáře mi tam moc nepomohou. A co jsem zatím vyzkoušel vyžadovalo závislosti, které jsem nemohl splnit.

Předm díky za tip

Klienti ACME.sh a Dehydrated si vystačí prakricky s libovolným shellem, OpenSSL a wget nebo curl. Tohle je tam problém splnit?

Ne. Autorita musí nějak ověřit oprávněnost požadavku na vystavení certifikátu. Pokud není možné použít HTTP ani DNS challenge, pak autorita certifikát odmítne vystavit.

Otázka je, proč by nebylo možné ověřit vlastnictví domény přes DNS. Pokud je to normální doména registrovaná kdekoli pod TLD, mělo by být možné ji přes DNS ověřit. Pokud je to nějaká vlastní doména (např. local), zvažte přechod na normální doménu – s těmihle lokálními doménami bude čím dál víc problémů. Už dnes u těchhle domén budete mít problém právě s certifikáty pro HTTPS a s DNSSEC.

Neřekl bych, že to přináší problémy – spíš někde může být problém dostat příslušný validační TXT záznam do veřejného DNS serveru. Ale není to neřešitelné. Prostě pak bude zónový soubor veřejného DNS serveru vypadat nějak takhle:

$ORIGIN                  example.com.
@                        SOA             ns.example.com.          hostmaster.exemplecom. (…)
@                        MX      10      a.smtp.example.com.
                         MX      20      b.smtp.example.com.
                         SPF             "…"
                         A               a.b.c.d
                         AAAA            a:b:c:d::1
www                      A               a.b.c.d
                         AAAA            a:b:c:d::1
mail                     A               a.b.c.d
                         AAAA            a:b:c:d::1
_acme-challenge          TXT             "…"
_acme-challenge.www      TXT             "…"
_acme-challenge.mail     TXT             "…"

$ORIGIN                  local.example.com.
_acme-challenge.intranet TXT             "…"
_acme-challenge.www      TXT             "…"
_acme-challenge.ucto     TXT             "…"

Tím máte zvalidované názvy www.local.example.com, intranet.local­.example.com a ucto.local.exam­ple.com, a kam si je nasměrujete na vnitřním DNS, to už je vaše věc.

Pripadne si pres https://kb.isc.org/article/AA-00851/0/Understanding-views-in-BIND-9-by-example.html nastavite, ze verejne IP dostavaji jine odpovedi nez znamene IP z vasi site a cele se to da udelat na jednom nameserveru.

Mimochodem kdyz jste startup a tesite se, ze vas nekdo koupi, tak pouziti .local je potom peklo pri integraci tech dvou siti ;)