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

271–280 of 308 posts

Re: Nginx introduces native support for ACME protocol

#271

Post by francislavoie »

stephenr wrote: post #246
kocial wrote: 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:

Given that Caddy has a history that includes choices like "refuse to start if LE cannot be contacted while a valid certificate exists on disk" I'm pretty happy to keep my certificate issuance separate from a web server. I need a tool to issue certs for a bunch of other services anyway, I don't really see how it became such a thing for people to want it embedded in their web server.

As we repeat every time this comes up, this was literally 8 years ago when the project was in its infancy and the project author was in the middle of exams, and it has not been true since. Caddy has been rewritten from the ground up since then, and comparing it to those old versions is dishonest.

Re: Nginx introduces native support for ACME protocol

#272

Post by rfmoz »

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.

The problem with DNS-01 is that you can only use one delegation a time. I mean, if you configure a wildcard cert with _acme-challenge.example.com in Google, you couldn't use it in Cloudflare, because it uses a single DNS authorization label (subdomain).

The solution has been evolving along these years and currently the las IETF draft is https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account...

The new proposal brings the dns-account-01 challenge, incorporating the ACME account URL into the DNS validation record name.

Re: Nginx introduces native support for ACME protocol

#273

Post by pgug »

dizhn wrote: post #262
pgug wrote: post #184

Earlier quoted context omitted.

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 here is how it's done, where you have a wildcard dns entry for subdomains of secret.domain.com. { acme_dns cloudflare oWN-HR__kxRoDhrixaQbI6M0uwS4bfXub4g4xia2 debug } *.secret.domain.com { @sso host sso.secret.domain.com handle @sso { reverse_proxy 192.168.200.4:9000 } @adguard host adguard.secret.domain.com handle @adguard { reverse_proxy 192.168.200.4:9000 } @forge host forge.secret.domain.com handle @forge {…

Thank you, I will try that later today.

Re: Nginx introduces native support for ACME protocol

#274

Post by xg15 »

jcgl wrote: post #253
account42 wrote: post #232

Earlier quoted context omitted.

> 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. Reverse-proxying or otherwise forwarding requests for .well-known/acme-challenge/ to a single server should be just as easy to set up as DNS-01.

But then you have to redistribute the cert from that single server to all the others. Which, yes, can be done. But then you've gotta write that glue yourself. What's more, you've now chosen a special snowflake server on whom renewals depend. In other words, no, it's not just as easy as setting up DNS-01. Different operational characteristics, and a need for bespoke glue code.

> But then you have to redistribute the cert from that single server to all the others.

Wouldn't you have to do that anyway? Or is the idea that each server requests and renews a separate cert for itself? That sounds as if you'd have to watch out for multiple servers stepping on each other's toes during the DNS-01 challenge, if there is ever a situation where two or more servers want to renew their cert at the same time.

Re: Nginx introduces native support for ACME protocol

#275

Post by cpach »

xg15 wrote: post #274
jcgl wrote: post #253

Earlier quoted context omitted.

But then you have to redistribute the cert from that single server to all the others. Which, yes, can be done. But then you've gotta write that glue yourself. What's more, you've now chosen a special snowflake server on whom renewals depend. In other words, no, it's not just as easy as setting up DNS-01. Different operational characteristics, and a need for bespoke glue code.

> But then you have to redistribute the cert from that single server to all the others. Wouldn't you have to do that anyway? Or is the idea that each server requests and renews a separate cert for itself? That sounds as if you'd have to watch out for multiple servers stepping on each other's toes during the DNS-01 challenge, if there is ever a situation where two or more servers want to renew their cert at the same t…

Yup. There’s an RFC draft that addresses this dilemma.

https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account...

Re: Nginx introduces native support for ACME protocol

#276

Post by snickerdoodle12 »

nadanke wrote: post #213
pgug wrote: post #184

Earlier quoted context omitted.

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.

In case it helps someone else, this is what I do:

    FROM caddy:2-builder AS builder

    RUN xcaddy build \
        --with github.com/caddy-dns/cloudflare \
        --with github.com/greenpau/caddy-security

    FROM caddy:2

    COPY --from=builder /usr/bin/caddy /usr/bin/caddy

    COPY Caddyfile /etc/caddy/Caddyfile
Then just build & run it via docker compose

Re: Nginx introduces native support for ACME protocol

#277

Post by tmcdos »

uncleJoe wrote: post #98
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.

no need to wait: https://en.angie.software/angie/docs/configuration/modules/h... (angie is the nginx fork lead by original nginx developers that left f5)

What are the main differences between Angie and freenginX.org ?

Re: Nginx introduces native support for ACME protocol

#278

Post by jcgl »

cpach wrote: post #275
xg15 wrote: post #274

Earlier quoted context omitted.

> But then you have to redistribute the cert from that single server to all the others. Wouldn't you have to do that anyway? Or is the idea that each server requests and renews a separate cert for itself? That sounds as if you'd have to watch out for multiple servers stepping on each other's toes during the DNS-01 challenge, if there is ever a situation where two or more servers want to renew their cert at the same t…

Yup. There’s an RFC draft that addresses this dilemma. https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account...

Afaiu, that's only a problem for trying to _delegate_ to multiple clients. But routine operation with multiple clients works just fine in my experience (doing multi-region load balancing). Multiple TXT records are created, I think (speaking off the top of my head).

Re: Nginx introduces native support for ACME protocol

#279

Post by 0x457 »

petee wrote: post #133
0x457 wrote: 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

I mean, you just repeated my explanation why supporting dns-01 in nginx isn't straightforward has http-01. I've explained why dns-01 challenge is still useful and might be required for some users.

Re: Nginx introduces native support for ACME protocol

#280

Post by petee »

0x457 wrote: post #279
petee wrote: post #133

Earlier quoted context omitted.

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

I mean, you just repeated my explanation why supporting dns-01 in nginx isn't straightforward has http-01. I've explained why dns-01 challenge is still useful and might be required for some users.

I misread your first paragraph, and was more responding to the second that I took as supporting the adding the dns implementation in reply to the OP.

It may still be required by some users, but I don't think that it makes sense for nginx

Post reply on HN