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

61–70 of 308 posts

Re: Nginx introduces native support for ACME protocol

#61

Post by chrismorgan »

lukeschlather wrote: post #32
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.

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.

Sounds like you’re doing it wrong. I don’t know about this native support, but I’d be very surprised if it was worse than the old way, which could just have Certbot put files in a path NGINX was already serving (webroot method), and then when new certificates are done send a signal for NGINX to reload its config. There should never be any downtime.

Re: Nginx introduces native support for ACME protocol

#62

Post by jeroenhd »

Spivak wrote: post #15
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.

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.

If you buy your domain with a bottom-of-the-barrel domain reseller and then not pay for decent DNS, you don't have the option.

Plus, it takes setting up an API key and most of the time you don't need a wildcard anyway.

Re: Nginx introduces native support for ACME protocol

#63

Post by Kwpolska »

lukeschlather wrote: post #32
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.

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.

Where would this downtime come from? Your setup is really badly configured if you need downtime to serve a new static file.

Re: Nginx introduces native support for ACME protocol

#64

Post by bityard »

johnisgood wrote: post #2

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. :/

I grew up on Apache and eventually became a wizard with its configuration and myriad options and failures modes. Later on, I got semi-comfortable with nginx which was a little simpler because it did less than Apache but you could still get a fairly complex configuration going if you're running weird legacy PHP apps for example.

When I tried using Caddy with something serious for the first time, I thought I was missing something. I thought, these docs must be incomplete, there has to be more to it, how does it know to do X based on Y, this is never going to work...

But it DID work. There IS almost nothing to it. You set literally the bare minimum of configuration you could possibly need, and Caddy figures out the rest and uses sane defaults. The docs are VERY good, there is a nice community around it.

If I had any complaint at all, it would be that the plugin system is slightly goofy.

Re: Nginx introduces native support for ACME protocol

#65

Post by john01dav »

andrewmcwatters wrote: post #49
ygjb wrote: post #48

Earlier quoted context omitted.

That's the great thing about open source. If you are not satisfied with the free labour's pace of implementing a feature you want, you can do it yourself!

Yes, absolutely! I would probably just pick a version to fork, set it to v1.0.0 for your org's production path, and then you'd know the behavior would never change. You could then merge updates back from upstream.

It's generally easier to just deal with breaking changes, since writing code is faster than gaining understanding and breaking changes in the external api are generally much better documented than internals.

Re: Nginx introduces native support for ACME protocol

#66

Post by jeroenhd »

creshal wrote: post #14
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 giant swiss army chainsaw that can do everything middlingly well, if you don't mind vibecoding your encryption intrastructure. But a clean solution it usually isn't. (That said, I'm not too thrilled by this implementation. How are renewals and revocations handled, and how can the processes be debugged? I hope the docs get updated soon.)

Certbot always worked fine for me. It autodetects just about everything and takes care of just about everything, unless you manually instruct it what to do (i.e. re-use a specific CSR) and then it does what you tell it to do.

It's not exactly an Ansible/Kubernetes-ready solution, but if you use those tools you already know a tool that solves your problem anyway.

Re: Nginx introduces native support for ACME protocol

#67

Post by ctxc »

josegonzalez wrote: post #47

This is great. Dokku (of which I am the maintainer) has a hokey solution for this with our letsencrypt plugin, but thats caused a slew of random issues for users. Nginx sometimes gets "stuck" reloading and then can't find the endpoint for some reason. The fewer moving knobs, the better. That said, its going to take quite some time for this to land in stable repositories for Ubuntu and Debian, and it doesn't (yet?) ha…

Hey! Great to see you here.

I tried dokku (and still am!) and it is so hard getting started.

For reference, - I've used Coolify successfully where it required me to create a Github app to deploy my apps on pushes to master - I've written GH actions to build and deploy containers to big cloud

This page is what I get if I want to achieve the same, and it's completely a reference book approach - I feel like I'm reading an encyclopedia. https://dokku.com/docs/deployment/methods/git/#initializing-...

Contrast it with this, which is INSTANTLY useful and helps me deploy apps hot off the page: https://coolify.io/docs/knowledge-base/git/github/integratio...

What I would love to see for Dokku is tutorials for popular OSS apps and set-objective/get-it-done style getting started articles. I'd LOVE an article that takes me from baremetal to a reverse proxy+a few popular apps. Because the value isn't in using Dokku, it's in using Dokku to get to that state.

I'm trying to use dokku for my homeserver.

Ideally I want a painless, quick way to go from "hey here's a repo I like" to "deployed on my machine" with Dokku. And then once that works, peek under the hood.

Re: Nginx introduces native support for ACME protocol

#68

Post by kijin »

chrismorgan wrote: post #61
lukeschlather wrote: post #32

Earlier quoted context omitted.

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.

Sounds like you’re doing it wrong. I don’t know about this native support, but I’d be very surprised if it was worse than the old way, which could just have Certbot put files in a path NGINX was already serving (webroot method), and then when new certificates are done send a signal for NGINX to reload its config. There should never be any downtime.

Certbot has a "standalone" mode that occupies port 80 and serves /.well-known/ by itself.

Whoever first recommended using that mode in anything other than some sort of emergency situation needs to be given a firm kick in the butt.

Certbot also has a mode that mangles your apache or nginx config files in an attempt to wire up certificates to your virtual hosts. Whoever wrote the nginx integration also needs a butt kick, it's terrible. I've helped a number of people fix their broken servers after certbot mangled their config files. Just because you're on a crusade to encrypt the web doesn't give you a right to mess with other programs' config files, that's not how Unix works!

Re: Nginx introduces native support for ACME protocol

#69

Post by cyberax »

cortesoft wrote: post #21
Spivak wrote: 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.

One problem with wildcards is that any service with *.foo.com can pretend to be any other service. This is an issue if you're using mutual TLS authentication and want to trust the server's certificate.

It'd be nice if LE could issue intermediary certificates constrained to a specific domain ( https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... ).

Re: Nginx introduces native support for ACME protocol

#70

Post by chaz6 »

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.
Post reply on HN