Live data from Hacker News

Nginx introduces native support for ACME protocol

blog.nginx.org

41–50 of 308 posts

Re: Nginx introduces native support for ACME protocol

#41
Good to see this. For those that weren't aware, there's been a low-effort solution with https://github.com/dehydrated-io/dehydrated, combined with a pretty simple couple of lines in your vhost config:

    location ^~ /.well-known/acme-challenge/ {
        alias ;
    }
Dehydrated has been around for a while and is a great low-overhead option for http-01 renewal automation.

Re: Nginx introduces native support for ACME protocol

#43
post #15
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.

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.

Re: Nginx introduces native support for ACME protocol

#44
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 use dns01 in my homelab with step-ca with caddy. It's a joy to use

Re: Nginx introduces native support for ACME protocol

#45

Good to see this. For those that weren't aware, there's been a low-effort solution with https://github.com/dehydrated-io/dehydrated , combined with a pretty simple couple of lines in your vhost config: location ^~ /.well-known/acme-challenge/ { alias ; } Dehydrated has been around for a while and is a great low-overhead option for http-01 renewal automation.

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 on major version 0 for years. It's just lazy and immature practice abusing semantic versioning. Maintainers can learn and grow. It's normal.

Dehydrated has been major version 0 for 7 years, it's probably past due.

See also React, LÖVE, and others that made 0.n.x jumps to n.x.x. (https://0ver.org)

CalVer: "If both you and someone you don't know use your project seriously, then use a serious version."

SemVer: "If your software is being used in production, it should probably already be 1.0.0."

https://0ver.org/about.html

Re: Nginx introduces native support for ACME protocol

#46

Good to see this. For those that weren't aware, there's been a low-effort solution with https://github.com/dehydrated-io/dehydrated , combined with a pretty simple couple of lines in your vhost config: location ^~ /.well-known/acme-challenge/ { alias ; } Dehydrated has been around for a while and is a great low-overhead option for http-01 renewal automation.

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?

Re: Nginx introduces native support for ACME protocol

#47
This is great. Dokku (of which I am the maintainer) has a hokey solution for this with our letsencrypt plugin, but thats caused a slew of random issues for users. Nginx sometimes gets "stuck" reloading and then can't find the endpoint for some reason. The fewer moving knobs, the better.

That said, its going to take quite some time for this to land in stable repositories for Ubuntu and Debian, and it doesn't (yet?) have DNS challenge support - meaning no wildcards - so I don't think it'll be useful for Dokku in the short-term at least.

Re: Nginx introduces native support for ACME protocol

#48

Good to see this. For those that weren't aware, there's been a low-effort solution with https://github.com/dehydrated-io/dehydrated , combined with a pretty simple couple of lines in your vhost config: location ^~ /.well-known/acme-challenge/ { alias ; } Dehydrated has been around for a while and is a great low-overhead option for http-01 renewal automation.

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…

That's the great thing about open source. If you are not satisfied with the free labour's pace of implementing a feature you want, you can do it yourself!

Re: Nginx introduces native support for ACME protocol

#49
post #48

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…

That's the great thing about open source. If you are not satisfied with the free labour's pace of implementing a feature you want, you can do it yourself!

Yes, absolutely! I would probably just pick a version to fork, set it to v1.0.0 for your org's production path, and then you'd know the behavior would never change.

You could then merge updates back from upstream.

Re: Nginx introduces native support for ACME protocol

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

I've been hoping to get ACME challenge delegation on traefik working for years already. The documentation says it supports it, but it simply fails every time.

If you have any idea how this tool would work on a docker swarm cluster, I'm all ears.

Post reply on HN