How does something like this work for a fleet of edge services, load balancing in distinct areas, but all share a certificate. Does each nginx instance go through the same protocol/setup steps?
Nginx introduces native support for ACME protocol
111–120 of 308 posts
Re: Nginx introduces native support for ACME protocol
#112Yeah, I don't want my webserver to turn into systemd and changing certificates. This is excessive functionality for something that should be handled elsewhere and drive the coordination of rolling certs.
Re: Nginx introduces native support for ACME protocol
#113> 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…
That is true and it is annoying. They should really just support RFC 2136 instead of building their own APIs. Lego also supports this and pretty much all DNS servers have it implemented. At least I can use it with my own DNS server...
Re: Nginx introduces native support for ACME protocol
#114How does something like this work for a fleet of edge services, load balancing in distinct areas, but all share a certificate. Does each nginx instance go through the same protocol/setup steps?
You'd get rate limited pretty hard by Let's Encrypt, but if you're rolling your own acme servers you could do it this way.
If you wanted to use LE though, you could use a more "traditional" cert renewal process somewhere out-of-band, and then provision the resulting keys/certs through whatever coordination thing you contrive (and HUP the nginxs)
Re: Nginx introduces native support for ACME protocol
#115How does something like this work for a fleet of edge services, load balancing in distinct areas, but all share a certificate. Does each nginx instance go through the same protocol/setup steps?
They don't need to share a single cert. Multiple certificates can be, and possibly should, issued for the same address (or set of addresses). This means that one front door server that gets popped doesn't expose all connections to the larger service.
Downside is obviously certificate maintenance increases, but ACME automated the vast majority of that work away.
Re: Nginx introduces native support for ACME protocol
#116Earlier quoted context omitted.
+1 for caddy. nginx is so 2007.
Caddy is just for developers that want to publish/test the thing they write. For power users or infra admins, nginx is still much more valuable. And yes, I use Caddy in my home lab and it's nice and all but it's not really flexible as nginx is.
We use Caddy across hundreds of apps with 10s of millions of requests per day in production.
Re: Nginx introduces native support for ACME protocol
#117Earlier quoted context omitted.
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.
Yup. I can’t wait for the day I can kill my caddy8s service. The best thing about caddy is the fact you can reload config, add sites, routes, without ever having to shutdown. Writing a service to keep your orchestration platform and your ingress in sync is meh. K8s has the events, DNS service has the src mesh records, you just need a way to tell caddy to send it to your backend. The feature should be done soon but th…
just send sighup to nginx and it will reload all the config—there's very few settings that require a restart
Re: Nginx introduces native support for ACME protocol
#118Just to check, this means we can use some extra lines in the nginx configuration as an alternative to installing and running certbot, right?
Also does it make it easier for there to be alternatives to Let's Encrypt?
Re: Nginx introduces native support for ACME protocol
#119Earlier quoted context omitted.
Yup. I can’t wait for the day I can kill my caddy8s service. The best thing about caddy is the fact you can reload config, add sites, routes, without ever having to shutdown. Writing a service to keep your orchestration platform and your ingress in sync is meh. K8s has the events, DNS service has the src mesh records, you just need a way to tell caddy to send it to your backend. The feature should be done soon but th…
just send sighup to nginx and it will reload all the config—there's very few settings that require a restart
Sure, how, from the container? The host it’s on? Caddy exposes this as an api.
Re: Nginx introduces native support for ACME protocol
#120It is a start. Maybe this will serve as a proof of concept that it can be done and then other protocols could be implemented.
Probably like many others here, I would very much like to see Cloudflare DNS support.