> 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.
Nginx introduces native support for ACME protocol
201–210 of 308 posts
Re: Nginx introduces native support for ACME protocol
#202Re: Nginx introduces native support for ACME protocol
#203Re: Nginx introduces native support for ACME protocol
#204Earlier 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.
Re: Nginx introduces native support for ACME protocol
#205Earlier 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…
https://community.cloudflare.com/t/restrict-scope-api-tokens...
Re: Nginx introduces native support for ACME protocol
#206Earlier 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.
Re: Nginx introduces native support for ACME protocol
#207Earlier 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.
Re: Nginx introduces native support for ACME protocol
#208Earlier 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.
- 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
#209Earlier 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.
Re: Nginx introduces native support for ACME protocol
#210This 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.
Admittedly this was on the back of trying to use nginx-unit, which was an overall bad experience, but ¯\_(ツ)_/¯