Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx introduces native support for ACME protocol

blog.nginx.org

Post reply on HN
Print view View original

131–140 of 308 posts

Re: Nginx introduces native support for ACME protocol

#131

Post by mholt »

chaz6 wrote: post #70
Shank wrote: 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.

One of Traefik's shortcomings with ACME is that you can only use one api key per DNS provider. This is problematic if you want to restrict api keys to a domain, or use domains belonging to two different accounts. I hope Nginx will not have the same constraint.

This is one of the main reasons Caddy stopped using lego for ACME and I wrote our own ACME stack.

Re: Nginx introduces native support for ACME protocol

#133

Post by petee »

0x457 wrote: post #35
creatonez wrote: post #25

Earlier quoted context omitted.

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.

dns-01 is just a challenge; which api or dns update system should nginx support then? Some API, AFXR, or UPDATE?

I think this is kinda the OPs point, nginx an http server, why should it be messing with dns? There are plenty of other acme clients to do this with ease

Re: Nginx introduces native support for ACME protocol

#134

Post by alanpearce »

Sesse__ wrote: post #31
hashworks wrote: post #27

Earlier quoted context omitted.

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

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

Hurricane Electric support a hidden primary as part of their free DNS nameserver service (do you actually want to expose your primary when someone else can handle the traffic?)

https://dns.he.net

Re: Nginx introduces native support for ACME protocol

#135

Post by reactordev »

RadiozRadioz wrote: post #129
reactordev wrote: post #73

Earlier quoted context omitted.

+1 for caddy. nginx is so 2007.

So a tool's value should be judged as inversely proportional to its age?

A tools value is in the eye of the beholder. Nginx has ceased being valuable to me when they decided to change licenses, go private equity, not adapt to orchestration needs, ignore http standards, and not release meaningful updates in a decade.

Re: Nginx introduces native support for ACME protocol

#136

Post by dizhn »

Saris wrote: post #91
elashri wrote: post #8

Earlier quoted context omitted.

What I really like about Caddy is their better syntax. I actually use nginx (via nginx proxy manager) and Traefik but recently I did one project with Caddy and found it very nice. I might get the time to change my selfhosted setup to use Caddy in the future but probably will go with something like pangolin [1] because it provides alternative to cloudflare tunnels too. [1] https://github.com/fosrl/pangolin

Caddy does have some bizarre limitations I've run into, particularly logging with different permissions when it writes the file, so other processes like promtail can read the logs. With Caddy you cannot change them, it always writes with very restrictive permissions. I find their docs also really hard to deal with, trying to figure out something that would be super simple on Nginx can be really difficult on Caddy, if…

You can have the binary self update with currently included plugins. I think the command line help says it's beta but has always worked fine for me.

Re: Nginx introduces native support for ACME protocol

#137

Post by thresh »

idoubtit wrote: post #124

A little mistake with this release: they packaged the ngx_http_acme_module for many Linux distributions, but "forgot" Debian stable. Oldstable and oldoldstable are listed in https://nginx.org/en/linux_packages.html (packages built today) but Debian 13 Trixie (released 4 days ago) is not there.

I'm currently working on getting the Trixie packages uploaded. It'll be there this week.

As you've said Debian 13 was released 4 days ago - it takes some time to spin up the infrastructure for a new OS (and we've been busy with other tasks, like getting nginx-acme and 1.29.1 out).

(I work for F5)

Re: Nginx introduces native support for ACME protocol

#139

Post by quicksilver03 »

clvx wrote: post #13
Shank wrote: 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.

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.

Is having one key per zone worth paying money for? It's on the list of features I'd like to implement for PTRDNS because it makes sense for my own use case, but I don't know if there's enough interest to make it jump to the top of this list.

Re: Nginx introduces native support for ACME protocol

#140

Post by orblivion »

9dev wrote: post #40
adontz wrote: 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.

That doesn't sound right to me. It's been in Debian and Ubuntu for a while:

* https://packages.debian.org/bullseye/certbot

* https://packages.ubuntu.com/jammy/certbot

Post reply on HN