Live data from Hacker News

Nginx introduces native support for ACME protocol

blog.nginx.org

31–40 of 308 posts

Re: Nginx introduces native support for ACME protocol

#31
post #13

Earlier quoted context omitted.

But you have to have your dns api key loaded and many dns providers don’t allow api keys per zone. I do like it but a compromise could be awful.

If you host a hidden primary yourself you get that easily.

Many DNS providers also don't support having an external primary.

Re: Nginx introduces native support for ACME protocol

#32
post #9

> The current preview implementation supports HTTP-01 challenges to verify the client’s domain ownership. DNS-01 is probably the most impactful for users of nginx that isn't public facing (i.e., via Nginx Proxy Manager). I really want to see DNS-01 land! I've always felt that it's also one of the cleanest because it's just updating some records and doesn't need to be directly tethered to what you're hosting.

Why would nginx ever need support for the DNS-01 challenge type? It always has access to `.well-known` because nginx is running an HTTP server for the entire lifecycle of the process, so you'd never need to use a lower level way of doing DV. And that seems to violate the principle of least privilege, since you now need a sensitive API token on the server.

Issuing a new certificate with the HTTP challenge pretty much requires you allow for 15 minutes of downtime. It's really not suitable for any customer-facing endpoint with SLAs.

Re: Nginx introduces native support for ACME protocol

#33
post #15

Earlier quoted context omitted.

I don't even know why anyone wouldn't use the DNS challenge unless they had no other option. I've found it to be annoying and brittle, maybe less so now with native web server support. And you can't get wildcards.

My work is mostly running internal services that aren’t reachable from the external internet. DNS is the only option. You can get wildcards with DNS. If you want *.foo.com, you just need to be able to set _acme-challenge.foo.com and you can get the wildcard.

Spivak is saying that the DNS method is superior (i.e you are agreeing - and I do too).

One reason I can think of for HTTP-01 / TLS-ALPN-01 is on-demand issuance, issuing the certificate when you get the request. Which might seem insane (and kinda is), but can be useful for e.g crazy web-migration projects. If you have an enormous, deeply levelled, domain sprawl that are almost never used but you need it up for some reason it can be quite handy.

(Another reason, soon, is that HTTP-01 will be able to issue certs for IP addresses: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...)

Re: Nginx introduces native support for ACME protocol

#34

For now I will stick to what works (nginx + certbot), but I will give this a try. Anyone tried it? Caddy sounds interesting too, but I am afraid of switching because what I have works properly. :/

Caddy has been great for me. I don't think you should switch if your current setup works but give it a try in a new project.

Re: Nginx introduces native support for ACME protocol

#35
post #9

> The current preview implementation supports HTTP-01 challenges to verify the client’s domain ownership. DNS-01 is probably the most impactful for users of nginx that isn't public facing (i.e., via Nginx Proxy Manager). I really want to see DNS-01 land! I've always felt that it's also one of the cleanest because it's just updating some records and doesn't need to be directly tethered to what you're hosting.

Why would nginx ever need support for the DNS-01 challenge type? It always has access to `.well-known` because nginx is running an HTTP server for the entire lifecycle of the process, so you'd never need to use a lower level way of doing DV. And that seems to violate the principle of least privilege, since you now need a sensitive API token on the server.

Because while Nginx always has access to .well-known, thing that validates on issuer side might not. I use DNS challenge to issue certificates for domains that resolve to IPs in my overlay network.

The issue is that supporting dns-01 is just supporting dns-01 it's providing a common interface to interact with different providers that implement dns-01.

Re: Nginx introduces native support for ACME protocol

#36

Earlier quoted context omitted.

My work is mostly running internal services that aren’t reachable from the external internet. DNS is the only option. You can get wildcards with DNS. If you want *.foo.com, you just need to be able to set _acme-challenge.foo.com and you can get the wildcard.

Spivak is saying that the DNS method is superior (i.e you are agreeing - and I do too). One reason I can think of for HTTP-01 / TLS-ALPN-01 is on-demand issuance, issuing the certificate when you get the request. Which might seem insane (and kinda is), but can be useful for e.g crazy web-migration projects. If you have an enormous, deeply levelled, domain sprawl that are almost never used but you need it up for some…

Oh I totally misread the comment.

Nevermind, I agree!

Re: Nginx introduces native support for ACME protocol

#38
The IT Roller Coaster in two reactions:

> Nginx Introduces Native Support for Acme Protocol

IT: “It’s about fucking time!

> The current preview implementation supports HTTP-01 challenges to verify the client’s domain ownership.

IT: “FUCK. Alright, domain registrar, mint me a new wildcard please, one of the leading web infrastructure providers still can’t do a basic LE DNS-01 pull in 2025.

Seriously. PKI in IT is a PITA and I want someone to SOLVE IT without requiring AD CAs or Yet Another Hyperspecific Appliance (YAHA). If your load balancer, proxy server, web server, or router appliance can’t mint me a basic Acme certificate via DNS-01 challenges, then you officially suck and I will throw your product out for something like Caddy the first chance I get.

While we’re at it, can we also allow DNS-01 certs to be issued for intermediate authorities, allowing internally-signed certificates to be valid via said Intermediary? That’d solve like, 99% of my PKI needs in any org, ever, forever.

Re: Nginx introduces native support for ACME protocol

#39
It seems like if you commit your NGINX config with these updates, you can have one less process to your deployment if you're doing something like:

    # https://certbot.eff.org/instructions?ws=other&os=ubuntufocal
    sudo apt-get -y install certbot
    # sudo certbot certonly --standalone
    
    ...
    
    # https://certbot.eff.org/docs/using.html#where-are-my-certificates
    # sudo chmod -R 0755 /etc/letsencrypt/{live,archive}

So, unfortunately, this support still seems more involved than using certbot, but at least one less manual step is required.

Example from https://github.com/andrewmcwattersandco/bootstrap-express

Re: Nginx introduces native support for ACME protocol

#40
post #5

certbot has an plugin for nginx, so I'm not sure why people think is was hard to use LetsEncrypt with nginx.

Certbot is a utility that can only be installed via snap. That crap won’t make it to our servers, and many other people view it the same way I do.

So this change is most welcome.

Post reply on HN