Live data from Hacker News

Nginx introduces native support for ACME protocol

blog.nginx.org

211–220 of 308 posts

Re: Nginx introduces native support for ACME protocol

#211

Earlier quoted context omitted.

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

Could you elaborate on the separate key per zone issue? It's possible to create different API keys which have only access to a specific zone, and I'm a non-enterprise user.

Re: Nginx introduces native support for ACME protocol

#212

Earlier quoted context omitted.

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

When setting up the API key, use the "Select zones to include or exclude." section. Works fine on the free account.

Re: Nginx introduces native support for ACME protocol

#213
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.

For wildcards you need a Caddy build that includes the dns plugin for your specific provider. There's a tool called xcaddy that helps with that. It's still kinda annoying because now you need to manage the binary for yourself but when I tried it with Hetzner it worked fine.

Re: Nginx introduces native support for ACME protocol

#214

Earlier quoted context omitted.

Well you can use an admin box and a script to request like 1000 different certs of different names through DNS-01. Copy the certs to the devices that need them. The big problem now is, you have ~5 days to constantly re-copy new certs and reboot the devices, thanks to LE's decision to be super annoying. If you want less annoying... pay for certs. Installing custom CA certs isn't that hard once you figure out how to do…

The problem I continue to encounter is that delegating this to colleagues or other teams is that - inevitably - someone thinks they're clever bypassing part or all of the procedure to, say, generate a wildcard cert and share its private key component with whoever asks for a cert, instead of going through approved processes. At PriorBigCo, we had a dedicated team who just handled global internal PKI, and despite a 72h…

Using CNAMEs with the _acme-challenge, plus API keys with fine-grained authorization, you can manage what each of those colleagues or teams can issue certs for. Disallowing wildcard certs for them, for example :)

Re: Nginx introduces native support for ACME protocol

#215
post #133
post #35

Earlier quoted context omitted.

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

[deleted]

Re: Nginx introduces native support for ACME protocol

#216
post #211

Earlier quoted context omitted.

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

Could you elaborate on the separate key per zone issue? It's possible to create different API keys which have only access to a specific zone, and I'm a non-enterprise user.

This allows you to restrict it to a domain (e.g. example.com) but not a sub-domain of that domain.

Re: Nginx introduces native support for ACME protocol

#217

Not gonna lie, setting up Nginx, Certbot inside docker is the biggest PITA ever. you need certificates to start the NGINX server but you need the NGINX server to issue certificates? see the problem? It is made infinitely worse by a tonne of online solutions and blog posts none of which I could ever get to work. I would really appreciate if someone has documented this extensively for docker compose. I dont want to use…

> you need certificates to start the NGINX server but you need the NGINX server to issue certificates?

I just pre-populate with a self-signed cert to start, though I'd have to check how to do that in docker.

Re: Nginx introduces native support for ACME protocol

#218

Earlier quoted context omitted.

This is really cool, but I find projects that have thousands of people depending on it not cutting a stable release really distasteful. Edit: Downvote me all you want, that's reality folks, if you don't release v1.0.0, the interface you consume can change without you realizing it. Don't consume major version 0 software, it'll bite you one day. Convince your maintainers to release stable cuts if they've been sitting o…

Distasteful by whom, the people depending on it? Surely not… the people providing free software at no charge, as is? Surely not… Maybe not distasteful by any one in particular, but just distasteful by fate or as an indicator of misaligned incentives or something?

> Distasteful by whom, the people depending on it? Surely not…

Why not?

Re: Nginx introduces native support for ACME protocol

#219
post #216
post #211

Earlier quoted context omitted.

Could you elaborate on the separate key per zone issue? It's possible to create different API keys which have only access to a specific zone, and I'm a non-enterprise user.

This allows you to restrict it to a domain (e.g. example.com) but not a sub-domain of that domain.

Ah I see, thanks for the clarification!

Re: Nginx introduces native support for ACME protocol

#220
post #171

The problem with the big open-source companies is that they are always very late to understand and implement the most basic innovations that come out. Caddy & Traefik did it long, long ago (half a decade ago), and after half a decade, we finally have ngxin supporting it too. Great move though, finally I won't have to manually run certbot :pray:

And the brilliant thing about open source projects is that if someone felt it was so important to have it built-in, they could have done so many years ago.
Post reply on HN