dehydrated-bigip-ansible VS lexicon

> I'm using the acme.sh client but the process will be similar no matter which client you choose to use.

Always nice to see some variety in clients along side the official Let's Encrypt one.

While we do use the official Python-based client at works at times, whenever I install it via apt, and it pulls in a whole bunch of dependencies, it's a bit disconcerting to me.

I'm a bit partial to dehydrated, which is a shell script (works under Bash and Zsh): I find it a lot easier to understand. It's handy to put on Linux/POSIX-based appliances like F5s, where the only prerequisites are Bash, cURL, and OpenSSL (and standard Unix tools like sed, grep, etc):

* https://devcentral.f5.com/s/articles/lets-encrypt-on-a-big-i...

* https://github.com/EquateTechnologies/dehydrated-bigip-ansib...

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.