Live data from Hacker News

Nginx introduces native support for ACME protocol

blog.nginx.org

221–230 of 308 posts

Re: Nginx introduces native support for ACME protocol

#221

I never saw it as a problem for nginx to just serve web content and let certbot handle cert renewals. Whatever happened to doing one thing well and making it composable? Fat tools that try to do everything inevitably suck at some important part.

This optional module makes simple cases simpler.

Having distinct tools for serving content and handling certs is not a problem, and nothing changes on this side. Moreover, the module won't cover every need.

BTW, cerbot is rather a "fat tool" compared to other acme tools like lego. I've had bad experiences with certbot in the past because it tried to do too much automatically and it's hard to diagnose – though I think certbot has been rewritten since then, since it has no more dependency on python zope.

Re: Nginx introduces native support for ACME protocol

#222

Not 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…

> you need certificates to start the NGINX server but you need the NGINX server to issue certificates? I just pre-populate with a self-signed cert to start, though I'd have to check how to do that in docker.

exactly! it all sounds easy unless you want to run stuff inside docker at which point there is a serious lack of documentation and resources

Re: Nginx introduces native support for ACME protocol

#223

Anybody know how this would work for multiple nginx backends or failover machines - as I assume it's only possible to auto-fetch certificates for the live machine. Is it expected that you would use scp or similar to copy certs from the live machine to the failover / new server?

You don’t need exactly the same cert for failover. You only need a valid certificate. You don’t even need the same cert for every entry in your load balancer. Client will pick a single IP address when resolved, then connect to it and will keep using that TLS connection for the whole session.

Re: Nginx introduces native support for ACME protocol

#224

I never saw it as a problem for nginx to just serve web content and let certbot handle cert renewals. Whatever happened to doing one thing well and making it composable? Fat tools that try to do everything inevitably suck at some important part.

Nginx with certbot is annoying to setup. Especially with HTTP challenge. Mostly because of a circular dependency. You need nginx to clear the challenge and once verboten gets a cert you need to reload nginx.

I switched to Lego because it has out of the box support for my domain registrar so I could use DNS instead of HTTP challenge. It’s also a single go binary which is much simpler to install than certbot.

Re: Nginx introduces native support for ACME protocol

#225

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…

DNS challenge is complicated by the fact that every registrar has their own API. HTTP is easier for nginx because it’s a single flow and it already does HTTP.

I’m sure nginx will get DNS but it’s still an open question when it will support your particular registrar or if at all.

Re: Nginx introduces native support for ACME protocol

#226
post #118

Just 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?

Yes, a few lines in the config and you don’t need certbot any more.

You can specify any ACME API base URL. It’s not just Let’s Encrypt.

Re: Nginx introduces native support for ACME protocol

#227
post #206
post #184

Earlier quoted context omitted.

I find the documentation for the syntax to be a bit lacking if you want to do anything that isn't very basic and how they want you to do it. For example, I want to use a wildcard certificate for my internal services to hide service names from certificate transparency logs, and I can't get the syntax working. Chatgpt and gemini also couldn't.

This integration doesn’t support the dns-01 challenge. So wildcard certs are out of the question at this point.

PS. Oh, this subthread is about Caddy, not Nginx. Nevermind my comment then!

Re: Nginx introduces native support for ACME protocol

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

if even PowerDNS doesn‘t support it :(

True for API but you can do DynDNS updates (RFC 2136), TSIG-authenticated on a per-zone basis. [1]

Can even be controlled quite granularly with a Lua-based updatepolicy, if you want e.g. restricting to only the ACME TXT records. [2]

[1] https://doc.powerdns.com/authoritative/dnsupdate.html

[2] https://github.com/PowerDNS/pdns/wiki/Lua-Examples-(Authorit...

Re: Nginx introduces native support for ACME protocol

#229
> Support for other challenges (TLS-ALPN, DNS -01) is planned in future.

Looking forward to this. HTTP-01 already works well enough for me with certbot (which I need for other services anyway and gives me more control over having multiple domains in one cert) but for wildcard certs there are not as many good solutions.

Re: Nginx introduces native support for ACME protocol

#230
post #68

Earlier quoted context omitted.

Sounds like you’re doing it wrong. I don’t know about this native support, but I’d be very surprised if it was worse than the old way, which could just have Certbot put files in a path NGINX was already serving (webroot method), and then when new certificates are done send a signal for NGINX to reload its config. There should never be any downtime.

Certbot has a "standalone" mode that occupies port 80 and serves /.well-known/ by itself. Whoever first recommended using that mode in anything other than some sort of emergency situation needs to be given a firm kick in the butt. Certbot also has a mode that mangles your apache or nginx config files in an attempt to wire up certificates to your virtual hosts. Whoever wrote the nginx integration also needs a butt kic…

Certbot also fights automation and provisioning with e.g. Andible by modifying config files to remember command line options if you ever need to do anything manually in an emergency.

It is a terrible piece of software. I use dehydrated which I'd much friendlier to automation.

Post reply on HN