lexicon VS lego

One of the biggest benefits of dehydrated is that it doesn't try to integrate with a DNS provider on its own. It just calls a hook, which can be implemented with a simple shell script[1]. The most popular third-party integration is lexicon[2], though you're not required to use Lexicon. (e.g. you're free to use awscli, gcloud, linode-cli, etc. to do the actual DNS record manipulation)

This means its dependencies footprint is much smaller, and allows you to do things that can be a nightmare to configure with Certbot or other alternatives. For example, at one of the scenarios I had to set up was that we had to query a credential via HashiCorp Vault, which is then used to cURL into an API endpoint. The shell script in total was pretty short (< 100 LOC) and it worked extremely well.

[1]: https://github.com/dehydrated-io/dehydrated/blob/master/docs...

[2]: https://github.com/AnalogJ/lexicon

A reminder that if you an internal-only server where the typical http-01' verification connection method will not work, especially if you cannot easily/dynamically update DNS records, one can use dns-01* by using DNS aliasing/CNAME:

* https://dan.langille.org/2019/02/01/acme-domain-alias-mode/

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

So if you want a cert for www.internal.example.com, you will first have do a one-time change to have a _acme-challenge.www.internal… CNAME created to point to any other (sub-)domain where you can easily update things dynamically, e.g., www-internal.example-dnsapi.com.

When request the cert for "www.internal…", LE/ACME will look up the corresponding _acme-challenge record, and go to "_acme-challenge.www-internal.example-dnsapi.com. The nonce token will be there in the 'final' destination following the CNAME in a TXT, which shows LE/ACME that you control the DNS chain.

To do the DNS updating, you can use a CLI/Python library like Lexicon, which supports dozens of APIs:

* https://github.com/AnalogJ/lexicon

This leverages the ACME DNS server which has a REST API:

* https://github.com/joohoi/acme-dns

If your DNS provider has an API, you can hook into that for internal-only web servers; this handy code supports several dozen APIs so you don't have to re-invent the wheel:

* https://github.com/AnalogJ/lexicon

* https://pypi.org/project/dns-lexicon/

* https://dns-lexicon.readthedocs.io/en/latest/user_guide.html

> It even comes preconfigured for various DNS providers[2]

Also, CLI utility that supports a bunch of APIs:

* https://github.com/AnalogJ/lexicon

Then, you can use ddclient, which supports many DNS services (including those providing DynDNS protocol), or you can write a Python script using the dns-lexicon module to manipulate the DNS records over the API.

Self contained but hardly a tiny supply chain attack surface: https://github.com/go-acme/lego/blob/master/go.sum

This ACME client looks promising, but I haven’t tried it yet: https://github.com/go-acme/lego

My favorite method of obtaining certificates is with lets encrypt and LEGO

Caddy where possible, and acme.sh or lego where not.

Depend on host's capability... - lego - dehydrated - caddy - in case it already works as a web server, it will automatically issue and renew certs

u/gregtwallace maybe in the short term until you write your own, you could provide a hook into one of the many ACME client implementations which do DNS-01 and support the majority of major DNS provider APIs out of the box? That would make your (really great!) project much more widely usable.