LWN: Comments on "NGINX adds native support for ACME protocol"

Why a half ACME client?

WolfWings — Tue, 19 Aug 2025 03:53:35 +0000

It's not 'half' a client to only support a subset of all possible challenge types, as the HTTP-01 and DNS-01 challenges in particular cover wildly different use cases which are differently convenient for different scenarios.

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?

"Smaller attack surface"?

Cyberax — Sat, 16 Aug 2025 02:36:04 +0000

Yours too?!?

(I found an AccuBeat rubidium frequency standard on eBay for cheap and couldn't hold myself back from buying it)

"Smaller attack surface"?

jdulaney — Sat, 16 Aug 2025 00:04:05 +0000

I'll have you know my web server is connected to a GPS disciplined rubidium oscillator

Why a half ACME client?

farnz — Fri, 15 Aug 2025 15:13:49 +0000

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?

ttuttle — Fri, 15 Aug 2025 15:02:04 +0000

Who decides which challenge is used -- the CA or the user? That is, what's wrong with implementing only one challenge, if it's functional?

"Smaller attack surface"?

alp — Thu, 14 Aug 2025 22:57:13 +0000

Yeah, the locking is downright ugly, but for some applications, given the concurrent userbase size, and aggressive enough connection reuse and TLS session tickets, it works out.

NGINX and certificate management

rbtree — Thu, 14 Aug 2025 18:13:43 +0000

ZeroSSL used to be the default, but now it's just a fallback for when Let's Encrypt is not available.

https://caddyserver.com/docs/caddyfile/directives/tls#acme

"Smaller attack surface"?

Cyberax — Thu, 14 Aug 2025 17:51:43 +0000

> Certainly it would be possible for the software case, where the isolation is process isolation or similar rather than potentially separate hardware - still a significant obstacle for most realistic attacks.

Even for software-based HSMs the PKCS interface is not scalable. It's typically implemented with a big lock around the storage, essentially limiting it to a single thread.

> Also you could do something like RFC 9345 "Delegated Credentials", there the idea is you get a certificate but the signatures from the certified key are used to delegate a further credential, so maybe you make one delegation every 30 minutes

Another option is to use constrained intermediary CAs, but neither them, nor delegated credentials are widely supported.

"Smaller attack surface"?

smurf — Thu, 14 Aug 2025 15:12:05 +0000

> a lot of machines will be wrong by exactly one hour due to "Daylight saving" nonsense

Certificate expiry is using UTC. The same is true (or should be true) for your local clock if the UI's time zone is set correctly.

So the people who fudge with their clocks instead of adjusting the timezone will learn to do this they way they should be doing it. *shrug*

Why a half ACME client?

iabervon — Thu, 14 Aug 2025 12:38:46 +0000

I think it's for systems where the web server has a private key of its own (not shared with any other software), and you want to get it a certificate for that key. This way, the private key is only ever known to the software that will terminate TLS under ordinary operation, and it uses the challenge type that software already handles for other purposes, resulting in a minimum of additional code having access to the key over what is needed for ordinary operation of this system.

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.

NGINX and certificate management

aszs — Thu, 14 Aug 2025 12:19:47 +0000

True... but in this case the subdomains are controlled by different users (and they have access to the cert). If they had wildcard certs they could spoof each other, so we need one per subdomain.

"Smaller attack surface"?

tialaramex — Thu, 14 Aug 2025 10:37:16 +0000

Certainly it would be possible for the software case, where the isolation is process isolation or similar rather than potentially separate hardware - still a significant obstacle for most realistic attacks.

Also you could do something like RFC 9345 "Delegated Credentials", there the idea is you get a certificate but the signatures from the certified key are used to delegate a further credential, so maybe you make one delegation every 30 minutes, and the delegated credential is only good for an hour, but clearly a hardware HSM can keep up with that rate even if the web server is using that credential millions of times per second. Stealing a delegated credential that you can use for at most one hour isn't good, but it's extremely time limited, if you have an attack for this in the morning but I fix it at lunch time then everything is fine before closing.

There are practical problems today but nothing which can't be addressed. RFC 9345 points out that clock skew is an issue, a lot of machines will be wrong by exactly one hour due to "Daylight saving" nonsense and others won't have accurate clocks, humans tend to treat 5-10 minutes as acceptable unless they're weird like me. In some applications you don't care - you can guarantee accurate clocks in intended clients, but general web serving won't be one of those.

NGINX and certificate management

NYKevin — Thu, 14 Aug 2025 06:47:29 +0000

You can get a wildcard certificate if you go to the bother of setting up DNS-01 validation instead of HTTP-01 validation.

Unfortunately, NGINX does not (yet) support that, so you pretty much have to use Certbot or something resembling it.

"Smaller attack surface"?

Cyberax — Thu, 14 Aug 2025 06:23:05 +0000

Does this work for TLS? The last time I checked, the hardware PKCS devices were limited to maybe a dozen requests per second.

Why a half ACME client?

witurnpled — Thu, 14 Aug 2025 02:03:10 +0000

The client is limited to the HTTP-01 challenge type (and written in Rust).

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.

"Smaller attack surface"?

alp — Thu, 14 Aug 2025 00:08:09 +0000

Some of us would like to, or have to, store the private key in a software (e.g., SoftHSM) or hardware module, and access it over PKCS #11, so that you can use but not steal the private key.

NGINX and certificate management

aszs — Wed, 13 Aug 2025 21:44:08 +0000

Yeah it's pretty nice and the certs are signed by ZeroSSL not Let's Encrypt -- they don't have the rate limits that Let's Encrypt does.. If you have a lot of subdomains that comes in handy!

HAProxy too

bbolli — Wed, 13 Aug 2025 20:58:09 +0000

HAProxy also has built-in support for ACME since version 3.2.0.

NGINX and certificate management

stephane — Wed, 13 Aug 2025 20:07:48 +0000

I have often found the automation of deploying Nginx + Nginx-Certbot + SSL configuration via Ansible to be a bit of a pain. The rather slow development and the curious security management by F5 made me switch to Caddy (https://caddyserver.com/).

The integration of SSL/TLS certificate management in Caddy is just fantastic, and so is everything else!

"Smaller attack surface"?

NYKevin — Wed, 13 Aug 2025 19:44:49 +0000

Yes, read access is by far the more dangerous permission here.

In most situations, there would also be the question of whether it's a good idea to add a bunch of parsing code to the HTTP server's codebase. But ACME takes place over TLS, and your counterparty is authenticated before the ACME code even runs. If you don't trust the same CA that is issuing your certificate in the first place, then you have far larger problems than a little extra parsing code.

"Smaller attack surface"?

HenrikH — Wed, 13 Aug 2025 19:20:43 +0000

Sounds like a marginal benefit since NGINX still needs read access to your private key so it can still do all the damage it wants and does not need to write a new key to your keystore to do any maleficence.

"Smaller attack surface"?

smurf — Wed, 13 Aug 2025 18:35:56 +0000

I would expect that a server that only serves HTTP(S), including the ".well-known" subpath, plus a separate program that writes to that (and to the cert storage) after renewing a certificate, has the smaller attack surface, at least compared to an NGINX server that does both in the same process. This way NGINX doesn't need write access to my cert store.

But maybe that's just me.