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

141–150 of 308 posts

Re: Nginx introduces native support for ACME protocol

#141

Post by abcdefg12 »

bityard wrote: post #43
Spivak wrote: post #15

Earlier quoted context omitted.

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.

The advantage to HTTP validation is that it's simple. No messing with DNS or API keys. Just fire up your server software and tell it what your hostname is and everything else happens in the background automagically.

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

Re: Nginx introduces native support for ACME protocol

#142

Post by abcdefg12 »

creatonez wrote: post #25
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.

Why would nginx ever need support for the DNS-01 challenge type? It always has access to `.well-known` because nginx is running an HTTP server for the entire lifecycle of the process, so you'd never need to use a lower level way of doing DV. And that seems to violate the principle of least privilege, since you now need a sensitive API token on the server.

Because you might have more than one server serving this domain

Re: Nginx introduces native support for ACME protocol

#143

Post by 0xbadcafebee »

stego-tech wrote: post #85
0xbadcafebee wrote: post #52

Earlier quoted context omitted.

> allowing internally-signed certificates to be valid via said Intermediary By design, nothing is allowed to delegate signing authority, because it would become an immediate compromise of everything that got delegated when your delegated authority got compromised. Since only CAs can issue certs, and CAs have to pass at least some basic security scrutiny, clients have assurance that the thing giving it a cert got said…

> If you want a non-trustworthy authority... go with a custom CA. It's intentionally difficult to do so. This is where I get rankled. In IT land, everything needs a valid certificate. The printer, the server, the hypervisor, the load balancer, the WAP’s UI, everything. That said, most things don’t require a publicly valid certificate. Perhaps Intermediate CA is the wrong phrase for what I’m looking for. Ideally it wo…

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 it for each application. I had to write all the docs on this for the IT team, specific to each application, because they were too lazy to do it. Painful at first, but easy after. To avoid more pain later, make the certs expire in 2036, retire before then.

Re: Nginx introduces native support for ACME protocol

#144

Post by cpach »

altairprime wrote: post #94
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.

Does DNS-01 support DNS-over-HTTPS to the registered domain name servers? If so, then it should be extremely simple to extend nginx to support DNS claims; if not, perhaps DNS-01 needs improvements.

When placing the order, you get a funny text string from the ACME provider. You need to create a TXT record that holds this value. How you create the TXT record is up to you and your DNS server – the ACME provider doesn’t care.

I don’t believe DNS-over-HTTPS is relevant in this context. AFAIK, it’s used by clients who want to query a DNS server, and not for an operator who wants to create a DNS record. (Please correct me if I’m wrong.)

Re: Nginx introduces native support for ACME protocol

#145

Post by cpach »

kijin wrote: post #77
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.

A practical problem with DNS-01 is that every DNS provider has a different API for creating the required TXT record. Certbot has more than a dozen plugins for different providers, and the list is growing. It shouldn't be nginx's job to keep track of all these third-party APIs. It would also be unreasonable to tell everyone to move their domains to a handful of giants like AWS and Cloudflare who already control so muc…

This is a very good point.

I wonder what a good solution to this would be? In theory, Nginx could call another application that handles the communication with the DNS provider, so that the user can tailor it to their needs. (The user could write it in Python or Go or whatever.) Not sure how robust that would be though.

Re: Nginx introduces native support for ACME protocol

#146

Post by hju22_-3 »

thaumaturgy wrote: post #74
andrewmcwatters wrote: post #45

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…

FWIW I have been using and relying on Dehydrated to handle LetsEncrypt automation for something like 10 years, at least. I think there was one production-breaking change in that time, and to the best of my recollection, it wasn't a Dehydrated-specific issue, it was a change to the ACME protocol. I remember the resolution for that being super easy, just a matter of updating the Dehydrated client and touching a config…

You've been using Dehydrated since its initial commit in December of 2015?

Re: Nginx introduces native support for ACME protocol

#147

Post by 0x0000000 »

cpach wrote: post #144
altairprime wrote: post #94

Earlier quoted context omitted.

Does DNS-01 support DNS-over-HTTPS to the registered domain name servers? If so, then it should be extremely simple to extend nginx to support DNS claims; if not, perhaps DNS-01 needs improvements.

When placing the order, you get a funny text string from the ACME provider. You need to create a TXT record that holds this value. How you create the TXT record is up to you and your DNS server – the ACME provider doesn’t care. I don’t believe DNS-over-HTTPS is relevant in this context. AFAIK, it’s used by clients who want to query a DNS server, and not for an operator who wants to create a DNS record. (Please correc…

The ACME provider makes a query to the DNS server to validate the record exists and contains the right "funny string". Parent's question was whether that query is/can be made via DoH.

Re: Nginx introduces native support for ACME protocol

#148

Post by karmakaze »

elashri wrote: post #8
dizhn wrote: 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.

What I really like about Caddy is their better syntax. I actually use nginx (via nginx proxy manager) and Traefik but recently I did one project with Caddy and found it very nice. I might get the time to change my selfhosted setup to use Caddy in the future but probably will go with something like pangolin [1] because it provides alternative to cloudflare tunnels too. [1] https://github.com/fosrl/pangolin

Not only that but Nginx how the configuration is split up into all the separate modules is a lot of extra complexity that Caddy avoids by having a single coherent way of configuring its features.

Re: Nginx introduces native support for ACME protocol

#149

Post by reactordev »

mholt wrote: post #130
reactordev wrote: post #109

Earlier quoted context omitted.

Caddy is in use here in production. 14M requests an hour.

Where's that if I may ask?

Trust me, you don’t want to know. Just know - it’s working great and thank you. GovCloud be dragons.

Re: Nginx introduces native support for ACME protocol

#150

Post by cpach »

0x0000000 wrote: post #147
cpach wrote: post #144

Earlier quoted context omitted.

When placing the order, you get a funny text string from the ACME provider. You need to create a TXT record that holds this value. How you create the TXT record is up to you and your DNS server – the ACME provider doesn’t care. I don’t believe DNS-over-HTTPS is relevant in this context. AFAIK, it’s used by clients who want to query a DNS server, and not for an operator who wants to create a DNS record. (Please correc…

The ACME provider makes a query to the DNS server to validate the record exists and contains the right "funny string". Parent's question was whether that query is/can be made via DoH.

Perhaps I have poor imagination, but I fail to see why why it would matter?
Post reply on HN