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.
It's also been in Apache since 2018
Nginx introduces native support for ACME protocol
251–260 of 308 posts
Re: Nginx introduces native support for ACME protocol
#252Not gonna lie, setting up Nginx, Certbot inside docker is the biggest PITA ever. you need certificates to start the NGINX server but you need the NGINX server to issue certificates? see the problem? It is made infinitely worse by a tonne of online solutions and blog posts none of which I could ever get to work. I would really appreciate if someone has documented this extensively for docker compose. I dont want to use…
Usually the solution is to either not add ssl until you have the certs, or use selfsigned/snakeoil placeholder certs to get nginx started.
Personally I use dns everywhere. I have a central server running dehydrated and dns challenges every night which then rsyncs to all the servers (I'm going to replace it with vault). I kind of like having one place to check for certs
Re: Nginx introduces native support for ACME protocol
#253Earlier quoted context omitted.
No, that’s just one of the use-cases. Also: - wildcard certs. DNS-01 is a strict requirement here. - certs for a service whose TLS is terminated by multiple servers (e.g. load balancers). 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.
> 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.
Re: Nginx introduces native support for ACME protocol
#254Actually this was the reason I started using caddy, and easier config too!
Re: Nginx introduces native support for ACME protocol
#255certbot has an plugin for nginx, so I'm not sure why people think is was hard to use LetsEncrypt with nginx.
Certbot is a utility that can only be installed via snap. That crap won’t make it to our servers, and many other people view it the same way I do. So this change is most welcome.
It's a Python package you can install with pip, never ever installed it with Snap
Re: Nginx introduces native support for ACME protocol
#256Earlier quoted context omitted.
We use Caddy across hundreds of apps with 10s of millions of requests per day in production.
Oooh. Can you tell me more about this?
Sure. University / Government sector. I know quite some unis/projects in that field that switched to caddy, since gigantic ip ranges and deep subdomains with stakeholders of many different classes have certain PKI requirements and caddy makes using ACME easy. We deploy a self serving tool where people can generate EAB-Ids and Hmac keys for a sub domain they own.
Complex root domain routing and complex dynamic rewrite logic remains behind Apache/NginX/HaProxy, a lot of apps are then served in a container architecture with Caddy for easy cert renewal without relying on hacky certbot architectures. So we don't really serve that much traffic with just one instance. Also, a lot of our traffic is bots. More than one would think.
The basic configuration being tiny makes it the perfect fit for people with varying capabilities and know how when it comes to devops. As a devops engineer, I enjoy the easy integration with tailscale.
Re: Nginx introduces native support for ACME protocol
#257kind of feels unnecessary honestly...
Automating webroot is trivial and I would rather use an external rust utility to handle it than a module for nginx. I guess if you _only_ need certs for your website then this helps but I have certs for a lot of other things too, so I need an external utility anyway.
And no dns-01 support yet.
Re: Nginx introduces native support for ACME protocol
#258When will this land in mainline distros (no PPAs etc)? Given that a new stable version of Debian was released very recently, I would imagine August 2027 for Debian and maybe April 2026 for Ubuntu? In this very thread some people complain that certbot uses snap for distribution. Imagine making a feature release and having to wait 1-2 years until your users will get it on a broad scale.
Nginx maintains their own repository from which you can install nginx on your Ubuntu / Debian systems. I looked at Arch and they're a version behind, which surprised me. Must not be a heavily maintained arch package.
nginx has a stable release and a mainline release, which are packaged in Arch respectively as `nginx` and `nginx-mainline`. Both look up-to-date to me.
Re: Nginx introduces native support for ACME protocol
#259Earlier quoted context omitted.
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.
Just like you can point .well-known/acme-challenge/ to a writable directory you can also delegate the relevant DNS keys to a name server that you can more easily update.
Now you want me to rent or install at least two name servers, and then configure them, and then teach my web server how to send them rules?
That's so much more work than either of the options in my first comment. Aliasing a directory takes about one minute.
Re: Nginx introduces native support for ACME protocol
#260FINALLY!!!