Why a half ACME client?
Why a half ACME client?
Posted Aug 14, 2025 2:03 UTC (Thu) by witurnpled (subscriber, #156452)Parent article: NGINX adds native support for ACME protocol
Conceptually, why implement a "half" ACME client directly into the web server rather than let a full ACME implementation properly instrument NGINX for one of its challenge types. I don't see the advantage of the tight integration with the one challenge type here unless one is 1.) exclusively doing HTTP challenges and 2.) somehow does not trust the certbot/lego/... to properly setup NGINX?
Also, one mixes the responsibilities/concerns of the web server with TLS key management.
Posted Aug 14, 2025 12:38 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Of course, none of this makes sense if you want a keypair used by multiple programs for different services, such that there's no single program that terminates TLS for all connections, but that's only one of the two common use cases.
Posted Aug 15, 2025 15:02 UTC (Fri)
by ttuttle (subscriber, #51118)
[Link] (1 responses)
Posted Aug 15, 2025 15:13 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Posted Aug 19, 2025 3:53 UTC (Tue)
by WolfWings (subscriber, #56790)
[Link]
DNS-01 is require for wildcard certificates which is a common need, it's entirely standalone and detached from your webserver configuration, and it broadly needs to integrate to whatever proprietary API for TXT records your DNS registrar of choice uses; so as a result there's a lot of registrar-specific ACME clients. Are all those only 'half' an ACME client since they don't support HTTP-01 challenges?
Why a half ACME client?
Why a half ACME client?
Both CA and user decide what challenge to use; the CA offers support for various challenge types (with differing certificate issuance rules for each type - for example, a wildcard cert from LetsEncrypt needs a DNS challenge), the user selects one to use.
Why a half ACME client?
Why a half ACME client?