NGINX adds native support for ACME protocol

[Posted August 13, 2025 by jzb]

NGINX has announced the preview release of the nginx-acme module, which adds native support to NGINX for the Automatic Certificate Management Environment (ACME) protocol:

NGINX's native support for ACME brings a variety of benefits that simplify and enhance the overall SSL/TLS certificate management process. Being able to configure ACME directly using NGINX directives drastically reduces manual errors and eliminates much of the ongoing overhead traditionally associated with managing SSL/TLS certificates. It also reduces reliance on external tools like Certbot, creating a more secure and streamlined workflow with fewer vulnerabilities and a smaller attack surface.

"Smaller attack surface"?

Posted Aug 13, 2025 18:35 UTC (Wed) by smurf (subscriber, #17840) [Link] (10 responses)

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.

"Smaller attack surface"?

Posted Aug 13, 2025 19:20 UTC (Wed) by HenrikH (subscriber, #31152) [Link] (9 responses)

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"?

Posted Aug 13, 2025 19:44 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

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"?

Posted Aug 14, 2025 0:08 UTC (Thu) by alp (subscriber, #136414) [Link] (7 responses)

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.

"Smaller attack surface"?

Posted Aug 14, 2025 6:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

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

"Smaller attack surface"?

Posted Aug 14, 2025 10:37 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (5 responses)

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.

"Smaller attack surface"?

Posted Aug 14, 2025 15:12 UTC (Thu) by smurf (subscriber, #17840) [Link]

> 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*

"Smaller attack surface"?

Posted Aug 14, 2025 17:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> 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"?

Posted Aug 14, 2025 22:57 UTC (Thu) by alp (subscriber, #136414) [Link]

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.

"Smaller attack surface"?

Posted Aug 16, 2025 0:04 UTC (Sat) by jdulaney (subscriber, #83672) [Link] (1 responses)

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

"Smaller attack surface"?

Posted Aug 16, 2025 2:36 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Yours too?!?

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

NGINX and certificate management

Posted Aug 13, 2025 20:07 UTC (Wed) by stephane (subscriber, #57867) [Link] (4 responses)

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!

NGINX and certificate management

Posted Aug 13, 2025 21:44 UTC (Wed) by aszs (subscriber, #50252) [Link] (3 responses)

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!

NGINX and certificate management

Posted Aug 14, 2025 6:47 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

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.

NGINX and certificate management

Posted Aug 14, 2025 12:19 UTC (Thu) by aszs (subscriber, #50252) [Link]

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.

NGINX and certificate management

Posted Aug 14, 2025 18:13 UTC (Thu) by rbtree (guest, #129790) [Link]

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

HAProxy too

Posted Aug 13, 2025 20:58 UTC (Wed) by bbolli (guest, #19153) [Link]

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

Why a half ACME client?

Posted Aug 14, 2025 2:03 UTC (Thu) by witurnpled (subscriber, #156452) [Link] (4 responses)

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.

Why a half ACME client?

Posted Aug 14, 2025 12:38 UTC (Thu) by iabervon (subscriber, #722) [Link]

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.

Why a half ACME client?

Posted Aug 15, 2025 15:02 UTC (Fri) by ttuttle (subscriber, #51118) [Link] (1 responses)

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?

Why a half ACME client?

Posted Aug 15, 2025 15:13 UTC (Fri) by farnz (subscriber, #17727) [Link]

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?

Posted Aug 19, 2025 3:53 UTC (Tue) by WolfWings (subscriber, #56790) [Link]

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?