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

161–170 of 308 posts

Re: Nginx introduces native support for ACME protocol

#161

Post by Dylan16807 »

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.

I don't know how to make my server log into my DNS, and I don't particularly want to learn how. Mapping .well-known is one line of config.

Wildcards are the only temptation.

Re: Nginx introduces native support for ACME protocol

#162

Post by ilogik »

supriyo-biswas wrote: post #76
reactordev wrote: post #73

Earlier quoted context omitted.

+1 for caddy. nginx is so 2007.

Only if they'd get the K8s ingress out of the WIP phase; I can't wait to possibly get rid of the cert-manager and ingress shenanigans you get with others.

Traefik seems to be ok for us

Re: Nginx introduces native support for ACME protocol

#163

Post by fmajid »

clvx wrote: post #13
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.

But you have to have your dns api key loaded and many dns providers don’t allow api keys per zone. I do like it but a compromise could be awful.

My company's DNS provider doesn't even have an API so I delegated to a subdomain, hosted it on PowerDNS, and used Lego to automate the ACME.

Re: Nginx introduces native support for ACME protocol

#164

Post by andreashaerter »

jacooper wrote: post #153
qwertox wrote: post #97

Earlier quoted context omitted.

You can make the NS record for the _acme-challenge.domain.tld point to another server which is under your control, that way you don't have to update the zone through your DNS hoster. That server then only needs to be able to resolve the challenges for those who query.

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.important.example.com.example.net

4. Your ACME client writes the challenge responses for important.example.com into a TXT at the unimportant _acme-challenge.example.net and has only API access to provider B. If this gets hacked and example.net lost you change the CNAMES and use a new domain whatever.tld as CNAME target.

acme.sh supports this (see https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...; this also works for wildcards as described there), most ACME clients do.

I also wrote an acme.sh Ansible role supporting this: https://github.com/foundata/ansible-collection-acmesh/tree/m.... Example values:

  [...]

  # certificate: "foo.example.com" with an additional "bar.example.com" SAN

  - domains:

    - name: "foo.example.com"

      challenge:  # parameters depend on type

        type: "dns"

        dns_provider: "dns_hetzner"

        # CNAME _acme-challenge.foo.example.com => _acme-challenge.foo.example.com.example.net

        challenge_alias: "foo.example.com.example.net"

    - name: "bar.example.com"

      challenge:

        type: "dns"

        dns_provider: "dns_inwx"

        # CNAME _acme-challenge.bar.example.com => _acme-challenge.example.net

        challenge_alias: "example.net"

  [...]

Re: Nginx introduces native support for ACME protocol

#165

Post by 8organicbits »

bananapub wrote: post #26
clvx wrote: post #13

Earlier quoted context omitted.

But you have to have your dns api key loaded and many dns providers don’t allow api keys per zone. I do like it but a compromise could be awful.

no you don't, you can just run https://github.com/joohoi/acme-dns anywhere, and then CNAME _acme_challenge.realdomain.com to aklsfdsdl239072109387219038712.acme-dns.anywhere.com. then your ACME client just talks to the ACME DNS api, which let's it do nothing at all aside from deal with challenges for that one long random domain.

There's a SaaS version as well, if you don't want to self-host.

https://docs.certifytheweb.com/docs/dns/providers/certifydns...

Re: Nginx introduces native support for ACME protocol

#166

Post by arjie »

Neat, that'll be nice to have. Currently I just use certbot and it does a pretty damn good job. I just set the HTTP:80 configuration and certbot will migrate it to HTTPS:443 and take care of the certificates and so on. For the moment, I'll probably stick to that till this is mature.

Re: Nginx introduces native support for ACME protocol

#167

Post by owenthejumper »

miggy wrote: post #54

It seems HAProxy also added ACME/DNS-01 challenge support in haproxy-3.3-dev6 very recently. https://www.mail-archive.com/haproxy@formilux.org/msg46035.h...

It added ACME in 3.2, the DNS challenge is coming next: https://www.haproxy.com/blog/announcing-haproxy-3-2#acme-pro...

Re: Nginx introduces native support for ACME protocol

#168

Post by cnst »

stego-tech wrote: post #38

The IT Roller Coaster in two reactions: > Nginx Introduces Native Support for Acme Protocol IT: “It’s about fucking time! ” > The current preview implementation supports HTTP-01 challenges to verify the client’s domain ownership. IT: “ FUCK. Alright, domain registrar, mint me a new wildcard please, one of the leading web infrastructure providers still can’t do a basic LE DNS-01 pull in 2025. ” Seriously. PKI in IT is…

You could always switch to the Angie fork if you require the DNS challenge type with the wildcard domains:

https://en.angie.software/angie/docs/configuration/modules/h...

Re: Nginx introduces native support for ACME protocol

#169

Post by yjftsjthsd-h »

reactordev wrote: post #135
RadiozRadioz wrote: post #129

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.

> when they decided to change licenses,

https://github.com/nginx/nginx/blob/master/LICENSE looks like a nice normal permissive license. I don't care that there's a premium version if all the features I want are in the OSS version.

Post reply on HN