Live data from Hacker News

Nginx introduces native support for ACME protocol

blog.nginx.org

201–210 of 308 posts

Re: Nginx introduces native support for ACME protocol

#201
post #70
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.

You can use CNAME to handle multiple DNS challenge providers. https://doc.traefik.io/traefik/reference/install-configurati...

Re: Nginx introduces native support for ACME protocol

#203
Anybody know how this would work for multiple nginx backends or failover machines - as I assume it's only possible to auto-fetch certificates for the live machine. Is it expected that you would use scp or similar to copy certs from the live machine to the failover / new server?

Re: Nginx introduces native support for ACME protocol

#204
post #183

Earlier quoted context omitted.

And you have two or more servers serving this domain you’re out of luck

And this is different from DNS how exactly? The key and resulting cert still needs to be distributed among your servers no matter which method is used.

With dns-01, multiple servers could, independently of each other, fetch a certificate for the same set of hostnames. Not sure if it’s a good idea though.

Re: Nginx introduces native support for ACME protocol

#205

Earlier quoted context omitted.

How?

CNAMEs. I do this for everything. Example: 1. Your main domain is important.example.com with provider A. No DNS API token for security. 2. Your throwaway domain in a dedicated account with DNS API is example.net with provider B and a DNS API token in your ACME client 3. You create _acme-challenge.important.example.com not as TXT via API but permanent as CNAME to _acme-challenge.example.net or _acme-challenge.importan…

This has blown my mind. Its been a constant source of frustration since Cloudflare stubbornly refuses to allow non-enterprise accounts to have a seperate key per zone. The thread requesting it is a masterclass in passive aggressiveness:

https://community.cloudflare.com/t/restrict-scope-api-tokens...

Re: Nginx introduces native support for ACME protocol

#206
post #184

Earlier quoted context omitted.

I agree. That, and the sane defaults are almost always nearly perfect for me. Here is the entire configuration for a TLS-enabled HTTP/{1.1,2,3} static server: something.example.com { root * /var/www/something.example.com file_server } That's the whole thing. Here's the setup of a WordPress site with all the above, plus PHP, plus compression: php.example.com { root * /var/www/wordpress encode php_fastcgi unix//run/php…

I find the documentation for the syntax to be a bit lacking if you want to do anything that isn't very basic and how they want you to do it. For example, I want to use a wildcard certificate for my internal services to hide service names from certificate transparency logs, and I can't get the syntax working. Chatgpt and gemini also couldn't.

This integration doesn’t support the dns-01 challenge. So wildcard certs are out of the question at this point.

Re: Nginx introduces native support for ACME protocol

#207

Earlier quoted context omitted.

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.

Private equity? Either there’s a story I’m missing, or you’re mischaracterizing F5 as PE.

Re: Nginx introduces native support for ACME protocol

#208
post #172

Earlier quoted context omitted.

Because nginx, as an HTTP server, could answer the query?

At that point you might as well use the HTTP-01 challenge. I think the whole utility of DNS-01 is that you can use it if you don't want to expose the HTTP server to the internet.

No, that’s just one of the use-cases. Also:

- wildcard certs. DNS-01 is a strict requirement here. - certs for a service whose TLS is terminated by multiple servers (e.g. load balancers). DNS-01 is a practical requirement here because only one of the terminating servers would be able to respond during an HTTP or ALPN challenge.

Re: Nginx introduces native support for ACME protocol

#209
post #208
post #172

Earlier quoted context omitted.

At that point you might as well use the HTTP-01 challenge. I think the whole utility of DNS-01 is that you can use it if you don't want to expose the HTTP server to the internet.

No, that’s just one of the use-cases. Also: - wildcard certs. DNS-01 is a strict requirement here. - certs for a service whose TLS is terminated by multiple servers (e.g. load balancers). DNS-01 is a practical requirement here because only one of the terminating servers would be able to respond during an HTTP or ALPN challenge.

Ah, that makes sense. Thanks!

Re: Nginx introduces native support for ACME protocol

#210
post #3

This is pretty big. Caddy had this forever but not everybody wants to use caddy. It'll probably eat into the user share of software like Traefik.

I felt the same but switched to Caddy for my reverse proxy last year and have had a great experience.

Admittedly this was on the back of trying to use nginx-unit, which was an overall bad experience, but ¯\_(ツ)_/¯

Post reply on HN