[HN Gopher] Nginx introduces native support for ACME protocol
___________________________________________________________________
Nginx introduces native support for ACME protocol
Author : phickey
Score : 437 points
Date : 2025-08-13 15:41 UTC (7 hours ago)
(HTM) web link (blog.nginx.org)
(TXT) w3m dump (blog.nginx.org)
| johnisgood wrote:
| For now I will stick to what works (nginx + certbot), but I will
| give this a try. Anyone tried it?
|
| Caddy sounds interesting too, but I am afraid of switching
| because what I have works properly. :/
| roywashere wrote:
| I like it!!! I am using Apache mod_md on Debian for personal
| project. That is working fine but when setting up a new site it
| somehow required two Apache restarts which is not super smooth
| KronisLV wrote:
| It's interesting that mod_md is so unknown:
| https://httpd.apache.org/docs/2.4/mod/mod_md.html
|
| But also hey, now we have built-in ACME support in all the
| mainstream web servers: Nginx, Caddy and Apache2! Ofc Caddy
| will be the most polished, since that is one of its main
| selling points.
| orphea wrote:
| Caddy has been great for me. I don't think you should switch if
| your current setup works but give it a try in a new project.
| bityard wrote:
| I grew up on Apache and eventually became a wizard with its
| configuration and myriad options and failures modes. Later on,
| I got semi-comfortable with nginx which was a little simpler
| because it did less than Apache but you could still get a
| fairly complex configuration going if you're running weird
| legacy PHP apps for example.
|
| When I tried using Caddy with something serious for the first
| time, I thought I was missing something. I thought, these docs
| must be incomplete, there has to be more to it, how does it
| know to do X based on Y, this is never going to work...
|
| But it DID work. There IS almost nothing to it. You set
| literally the bare minimum of configuration you could possibly
| need, and Caddy figures out the rest and uses sane defaults.
| The docs are VERY good, there is a nice community around it.
|
| If I had any complaint at all, it would be that the plugin
| system is slightly goofy.
| dizhn wrote:
| 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.
| elashri wrote:
| 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
| kstrauser wrote:
| I agree. That, and the sane defaults are almost always nearly
| perfect for me. Here is the entire configuration for a TLS-
| enabled HTTP/{1.1,2,3} static server:
| something.example.com { root *
| /var/www/something.example.com file_server }
|
| That's the whole thing. Here's the setup of a WordPress site
| with all the above, plus PHP, plus compression:
| php.example.com { root * /var/www/wordpress
| encode php_fastcgi unix//run/php/php-version-fpm.sock
| file_server }
|
| You can tune and tweak all the million other options too, of
| course, but you don't _have_ to for most common use cases. It
| Just Works more than any similarly complex server I 've ever
| been responsible for.
| dizhn wrote:
| I checked out pangolin too recently but then I realized that
| I already have Authentik and using its embedded (go based)
| proxy I don't really need pangolin.
| Saris wrote:
| Caddy does have some bizarre limitations I've run into,
| particularly logging with different permissions when it
| writes the file, so other processes like promtail can read
| the logs. With Caddy you cannot change them, it always writes
| with very restrictive permissions.
|
| I find their docs also really hard to deal with, trying to
| figure out something that would be super simple on Nginx can
| be really difficult on Caddy, if it's outside the scope of
| 'normal stuff'
|
| The other thing I really don't like is if you install via a
| package manager to get automated updates, you don't get any
| of the plugins. If you want plugins you have to build it
| yourself or use their build service, and you don't get
| automatic updates.
| francislavoie wrote:
| Actually, you can set the permissions for log files now.
| See
| https://caddyserver.com/docs/caddyfile/directives/log#file
| Saris wrote:
| Oh good to know!
|
| Do you know if Caddy can self update or if is there some
| other easy method? Manually doing it to get the
| cloudflare plugin is a pain.
| francislavoie wrote:
| No, you have to build Caddy with plugins. We provide
| xcaddy to make it easy. Sign up for notifications on
| github for releases, and just write yourself a tiny bash
| script to build the binary with xcaddy, and restart the
| service. You could potentially do a thing where you hook
| into apt to trigger your script after Caddy's deb package
| version changes, idk. But it's up to you to handle.
| nodesocket wrote:
| I use Caddy as my main reverse proxy into containers with
| CloudFlare based DNS let's encrypt. The syntax is intuitive
| and just works. I've used Traefik in the past with
| Kubernetes and while powerful the setup and grok ability
| has quite a bit steeper learning curve.
| dizhn wrote:
| You can have the binary self update with currently included
| plugins. I think the command line help says it's beta but
| has always worked fine for me.
| karmakaze wrote:
| 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.
| thrown-0825 wrote:
| Definitely. I use traefik for some stuff at home and will
| likely swap it out now.
| grim_io wrote:
| I configure traefik by defining a few docker labels on the
| services themselves. No way I'm going back to using the
| horrible huge nginx config.
| tgv wrote:
| I switched over to caddy recently. Nginx' non-information about
| the http 1 desync problem drove me over. I'm not going to wait
| for something stupid to happen or an auditor ask me questions
| nginx doesn't answer.
|
| Caddy is really easier than nginx. For starters, I now have
| templates that cover the main services and their test services,
| and the special service that runs for an education institution.
| Logging is better. Certificate handling is perfect (for my
| case, at least). And it has better metrics.
|
| Now I have to figure out plugins though, because caddy doesn't
| have rate limiting and some stupid bug in powerbi makes a
| single user hit certain images 300.000 times per day. That's a
| bit of a downside.
| dekobon wrote:
| I did a google search for the desync problem and found this
| page: https://my.f5.com/manage/s/article/K30341203
|
| This type of thing is out of my realm of expertise. What
| information would you want to see about the problem? What
| would be helpful?
| cobbzilla wrote:
| There's a section on renewals but no description of how it works.
| Is there a background thread/process? Or is it request-driven? If
| request-driven, what about some hostname that's (somehow) not
| seen traffic in >90 days?
| adontz wrote:
| certbot has an plugin for nginx, so I'm not sure why people think
| is was hard to use LetsEncrypt with nginx.
| orblivion wrote:
| From a quick look it seems like a command you use to
| reconfigure nginx? And that's separate from auto-renewing the
| cert, right?
|
| Maybe not hard, but Caddy seems like even less to think about.
| orblivion wrote:
| I guess I should compare to this new Nginx feature rather
| than Caddy. It seems like the benefit of this feature is that
| you don't have a tool to run, you have a config to put into
| place. So it's easier to deploy again if you move servers,
| and you don't have to think about making sure certbot is
| doing renewals.
| creshal wrote:
| Certbot is a giant swiss army chainsaw that can do everything
| middlingly well, if you don't mind vibecoding your encryption
| intrastructure. But a clean solution it usually isn't.
|
| (That said, I'm not too thrilled by this implementation. How
| _are_ renewals and revocations handled, and how can the
| processes be debugged? I hope the docs get updated soon.)
| jeroenhd wrote:
| Certbot always worked fine for me. It autodetects just about
| everything and takes care of just about everything, unless
| you manually instruct it what to do (i.e. re-use a specific
| CSR) and then it does what you tell it to do.
|
| It's not exactly an Ansible/Kubernetes-ready solution, but if
| you use those tools you already know a tool that solves your
| problem anyway.
| jddj wrote:
| From the seeming consensus I was dreading setting let's encrypt
| up on nginx, until I did it and it was and has been...
| Completely straightforward and painless.
|
| Maybe if you step off the happy path it gets hairy, but I found
| the default certbot flow to be easy.
| 9dev wrote:
| 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.
| orblivion wrote:
| That doesn't sound right to me. It's been in Debian and
| Ubuntu for a while:
|
| * https://packages.debian.org/bullseye/certbot
|
| * https://packages.ubuntu.com/jammy/certbot
| 9dev wrote:
| Last I was concerned with, this was the situation:
|
| https://github.com/certbot/certbot/issues/8345#issuecomment
| -...
|
| That's been three years though. The EFF/Certbot team has
| lost so much goodwill with me over that, I won't go back.
| bityard wrote:
| Maybe it's better these days, but even as an experienced
| systems administrator, I found certbot _incredibly_ annoying to
| use in practice. They tried to make it easy and general-purpose
| for beginners to web hosting, but they did it with a lot of
| magic that does Weird Stuff to your host and server
| configuration. It probably works great if you're in an
| environment where you just install things via tarball, edit
| your config files with Nano, and then rarely ever touch the
| whole setup again.
|
| But if you're someone who needs tight control over the host
| configuration (managed via Ansible, etc) because you need to
| comply with security standards, or have the whole setup
| reproducible for disaster recovery, etc, then solutions like
| acme.sh or LEGO are far smaller, just as easy to configure, and
| in general will not surprise you.
| do_not_redeem wrote:
| It looks like this isn't included by default with the base nginx,
| but requires you to install it as a separate module. Or am I
| wrong?
|
| https://github.com/nginx/nginx-acme
| bhaney wrote:
| Nginx itself is mostly just a collection of modules, and it's
| up to the one building/packaging the nginx distribution to
| decide what goes in it. By default, nginx doesn't even build
| the ssl or gzip modules (though thankfully it does build the
| http module by default). Historically it only had static
| modules, which needed to be enabled or disabled at compile
| time, but now it has dynamic modules that can be compiled
| separately and loaded at runtime. Some older static modules now
| have the option of being built as dynamic modules, and new
| modules that can be written as dynamic modules generally are. A
| distro can choose to package a new dynamic module in their base
| nginx package, as a separate package, or not at all.
|
| In a typical distro, you would normally expect one or more
| virtual packages representing a profile (minimal, standard,
| full, etc) that depends on a package providing an nginx binary
| with every reasonable static-only module enabled, plus a number
| of separately packaged dynamic modules.
| timw4mail wrote:
| Yes, that is correct.
| Shank wrote:
| > 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.
| clvx wrote:
| 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.
| grim_io wrote:
| Sounds like a DNS provider problem. Why would Nginx feel the
| need to compromise because of some 3rd party implementation
| detail?
| toomuchtodo wrote:
| Because users would pick an alternative solution that meets
| their needs when they don't have leverage or ability to
| change DNS provider. Have to meet users where they are when
| they have options.
| bananapub wrote:
| 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.
| rglullis wrote:
| 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.
| Arnavion wrote:
| You can do it with an NS record, ie
| _acme_challenge.realdomain.com pointing to the DNS server
| that you can program to serve the challenge response. No
| need to make a CNAME and involve an additional domain in
| the middle.
| aflukasz wrote:
| Yeah, but then you can just as well use http-01 with like
| same effort.
| gruez wrote:
| no, because dns supports wildcard certificates, unlike
| http.
| aflukasz wrote:
| Ah, good point.
| cpach wrote:
| dns-01 is also good for services on a private network.
| 8organicbits wrote:
| There's a SaaS version as well, if you don't want to self-
| host.
|
| https://docs.certifytheweb.com/docs/dns/providers/certifydn
| s...
| hashworks wrote:
| If you host a hidden primary yourself you get that easily.
| Sesse__ wrote:
| Many DNS providers also don't support having an external
| primary.
| nulbyte wrote:
| Do most of them let you add an NS record?
| qwertox wrote:
| And if they don't, you might consider switching to
| Cloudflare for DNS hosting.
| alanpearce wrote:
| Hurricane Electric support a hidden primary as part of
| their free DNS nameserver service (do you actually want
| to expose your primary when someone else can handle the
| traffic?)
|
| https://dns.he.net
| xiconfjs wrote:
| if even PowerDNS doesn't support it :(
| ddtaylor wrote:
| It's a bit of a pain in the ass, but you can actually just
| publish the DNS records yourself. It's clear they are on the
| way out though as I believe it's only a 30 day valid
| certificate or something.
|
| I use this for my Jellyfin server at home so that anyone can
| just type in blah.foo regardless of if their device supports
| anything like mDNS, as half the devices claim to support it
| but do not correctly.
| qwertox wrote:
| You can make the NS record for the _acme-challenge.domain.tld
| point to another server which is under your control, that way
| you don't have to update the zone through your DNS hoster.
| That server then only needs to be able to resolve the
| challenges for those who query.
| jacooper wrote:
| How?
| dwood_dev wrote:
| Usually you just CNAME it.
|
| You can cname _acme-challenge.foo.com to foo.bar.com.
|
| Now, if when you do the DNS challenge, you make a TXT at
| foo.bar.com with the challenge response, through CNAME
| redirection, the TXT record is picked up as if it were
| directly at _acme-challenge.foo.com. You can now issue
| wildcard certs for anything for foo.com.
|
| I have it on my backlog to build an automated solution to
| this later this year to handle this for hundreds of
| individual domains and then put the resulting
| certificates in AWS secrets manager.
|
| I'm going to also see if I can make some sort of ACME
| proxy, so internal clients authenticate to me, but they
| cant control dns, so I make the requests on their behalf.
| We need to get prepared for ACME everywhere. In May 2026,
| its 200 day certs, it only goes down from there.
| andreashaerter wrote:
| CNAMEs. I do this for everything. Example:
|
| 1. Your main domain is important.example.com with
| provider A. No DNS API token for security.
|
| 2. Your throwaway domain in a dedicated account with DNS
| API is example.net with provider B and a DNS API token in
| your ACME client
|
| 3. You create _acme-challenge.important.example.com not
| as TXT via API but permanent as CNAME to _acme-
| challenge.example.net or _acme-
| challenge.important.example.com.example.net
|
| 4. Your ACME client writes the challenge responses for
| important.example.com into a TXT at the unimportant
| _acme-challenge.example.net and has only API access to
| provider B. If this gets hacked and example.net lost you
| change the CNAMES and use a new domain whatever.tld as
| CNAME target.
|
| acme.sh supports this (see https://github.com/acmesh-
| official/acme.sh/wiki/DNS-alias-mo... this also works for
| wildcards as described there), most ACME clients do.
|
| I also wrote an acme.sh Ansible role supporting this:
| https://github.com/foundata/ansible-collection-
| acmesh/tree/m.... Example values: [...]
| # certificate: "foo.example.com" with an additional
| "bar.example.com" SAN - domains: - name:
| "foo.example.com" challenge: # parameters
| depend on type type: "dns"
| dns_provider: "dns_hetzner" # CNAME _acme-
| challenge.foo.example.com => _acme-
| challenge.foo.example.com.example.net
| challenge_alias: "foo.example.com.example.net" -
| name: "bar.example.com" challenge:
| type: "dns" dns_provider: "dns_inwx"
| # CNAME _acme-challenge.bar.example.com => _acme-
| challenge.example.net challenge_alias:
| "example.net" [...]
| immibis wrote:
| General note: your DNS provider can be different from your
| registrar, even though most registrars are also providers,
| and you can be your own DNS provider. The registrar is who
| gets the domain name under your control, and the provider is
| who hosts the nameserver with your DNS records on it.
| qwertox wrote:
| Yes, and you can be your own DNS provider only for the
| challenges, everything else can stay at your original DNS
| provider.
| quicksilver03 wrote:
| Is having one key per zone worth paying money for? It's on
| the list of features I'd like to implement for PTRDNS because
| it makes sense for my own use case, but I don't know if
| there's enough interest to make it jump to the top of this
| list.
| yupyupyups wrote:
| It's time for DNS providers to start supporting TSIG + key
| management. This is a standardized way to manipulate DNS
| records, and has a very granular ACL.
|
| We don't need 100s of custom APIs.
|
| https://en.m.wikipedia.org/wiki/TSIG
| fmajid wrote:
| My company's DNS provider doesn't even have an API so I
| delegated to a subdomain, hosted it on PowerDNS, and used
| Lego to automate the ACME.
| Spivak wrote:
| 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.
| cortesoft wrote:
| My work is mostly running internal services that aren't
| reachable from the external internet. DNS is the only option.
|
| You can get wildcards with DNS. If you want *.foo.com, you
| just need to be able to set _acme-challenge.foo.com and you
| can get the wildcard.
| bryanlarsen wrote:
| > DNS is the only option
|
| DNS and wildcards aren't the only options. I've done
| annoying hacks to give internal services an HTTPS cert
| without using either.
|
| But they're the only _sane_ options.
| filleokus wrote:
| Spivak is saying that the DNS method is superior (i.e you
| are agreeing - and I do too).
|
| One reason I can think of for HTTP-01 / TLS-ALPN-01 is on-
| demand issuance, issuing the certificate when you get the
| request. Which might seem insane (and kinda is), but can be
| useful for e.g crazy web-migration projects. If you have an
| enormous, deeply levelled, domain sprawl that are almost
| never used but you need it up for some reason it can be
| quite handy.
|
| (Another reason, soon, is that HTTP-01 will be able to
| issue certs for IP addresses:
| https://letsencrypt.org/2025/07/01/issuing-our-first-ip-
| addr...)
| cortesoft wrote:
| Oh I totally misread the comment.
|
| Nevermind, I agree!
| Sharparam wrote:
| The comment is strangely worded, I too had to read it
| over a couple of times to understand what they meant.
| cyberax wrote:
| One problem with wildcards is that any service with
| *.foo.com can pretend to be any other service. This is an
| issue if you're using mutual TLS authentication and want to
| trust the server's certificate.
|
| It'd be nice if LE could issue intermediary certificates
| constrained to a specific domain ( https://datatracker.ietf
| .org/doc/html/rfc5280#section-4.2.1.... ).
| bityard wrote:
| 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.
| abcdefg12 wrote:
| And you have two or more servers serving this domain you're
| out of luck
| jeroenhd wrote:
| If you buy your domain with a bottom-of-the-barrel domain
| reseller and then not pay for decent DNS, you don't have the
| option.
|
| Plus, it takes setting up an API key and most of the time you
| don't need a wildcard anyway.
| Dylan16807 wrote:
| 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.
| creatonez wrote:
| 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.
| lukeschlather wrote:
| Issuing a new certificate with the HTTP challenge pretty much
| requires you allow for 15 minutes of downtime. It's really
| not suitable for any customer-facing endpoint with SLAs.
| kijin wrote:
| Only if you let certbot take down your normal nginx and
| occupy port 80 in standalone mode. Which it doesn't need
| to, if normal nginx can do the job by itself.
|
| When I need to use the HTTP challenge, I always configure
| the web server in advance to serve /.well-known/ from a
| certain directory and point certbot at it with `certbot
| certonly --webroot-path`. No need to take down the normal
| web server. Graceful reload. Zero downtime. Works with any
| web server.
| chrismorgan wrote:
| 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.
| kijin wrote:
| 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 kick, it's terrible. I've helped a
| number of people fix their broken servers after certbot
| mangled their config files. Just because you're on a
| crusade to encrypt the web doesn't give you a right to
| mess with other programs' config files, that's not how
| Unix works!
| jofla_net wrote:
| Also, whoever decided that service providers were no
| longer autonomous to determine the expiration times of
| their own infrastructure's certificates should get that
| boot-to-the-head as well.
|
| It is not as if they couldn't already choose (to buy)
| such short lifetimes already.
|
| Authoritarianism at its finest.
| tomku wrote:
| Those choices and Certbot strongly encouraging snap
| installation was enough to get me to switch to
| https://go-acme.github.io/lego/, which I've been very
| happy with since. It's very stable and feels like it was
| built by people who actually operate servers.
| Kwpolska wrote:
| Where would this downtime come from? Your setup is really
| badly configured if you need downtime to serve a new static
| file.
| 0x457 wrote:
| Because while Nginx always has access to .well-known, thing
| that validates on issuer side might not. I use DNS challenge
| to issue certificates for domains that resolve to IPs in my
| overlay network.
|
| The issue is that supporting dns-01 is just supporting dns-01
| it's providing a common interface to interact with different
| providers that implement dns-01.
| petee wrote:
| dns-01 is just a challenge; which api or dns update system
| should nginx support then? Some API, AFXR, or UPDATE?
|
| I think this is kinda the OPs point, nginx an http server,
| why should it be messing with dns? There are plenty of
| other acme clients to do this with ease
| justusthane wrote:
| You can't use HTTP-01 if the server running nginx isn't
| accessible from the internet. DNS-01 works for that.
| chrismorgan wrote:
| Wildcard certificates are probably the most important answer:
| they're not available via HTTP challenge.
| abcdefg12 wrote:
| Because you might have more than one server serving this
| domain
| samgranieri wrote:
| I use dns01 in my homelab with step-ca with caddy. It's a joy
| to use
| reactordev wrote:
| +1 for caddy. nginx is so 2007.
| supriyo-biswas wrote:
| 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.
| reactordev wrote:
| 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 they need to ensure
| it works across K8s flavors.
| 01HNNWZ0MV43FF wrote:
| I think you can that with Nginx too, but the SWAG wrapper
| discourages it for some reason
| pushrax wrote:
| just send sighup to nginx and it will reload all the
| config--there's very few settings that require a restart
| reactordev wrote:
| Sure, how, from the container? The host it's on? Caddy
| exposes this as an api.
| ilogik wrote:
| Traefik seems to be ok for us
| darkwater wrote:
| 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.
| reactordev wrote:
| Caddy is in use here in production. 14M requests an hour.
| mholt wrote:
| Where's that if I may ask?
| reactordev wrote:
| Trust me, you don't want to know. Just know - it's
| working great and thank you. GovCloud be dragons.
| j-krieger wrote:
| We use Caddy across hundreds of apps with 10s of millions
| of requests per day in production.
| mholt wrote:
| Oooh. Can you tell me more about this?
| RadiozRadioz wrote:
| So a tool's value should be judged as inversely
| proportional to its age?
| mholt wrote:
| Maybe inversely proportional to how much the ecosystem
| moves around it.
| reactordev wrote:
| A tools value is in the eye of the beholder. Nginx has
| ceased being valuable to me when they decided to change
| licenses, go private equity, not adapt to orchestration
| needs, ignore http standards, and not release meaningful
| updates in a decade.
| yjftsjthsd-h wrote:
| > when they decided to change licenses,
|
| https://github.com/nginx/nginx/blob/master/LICENSE looks
| like a nice normal permissive license. I don't care that
| there's a premium version if all the features I want are
| in the OSS version.
| chaz6 wrote:
| One of Traefik's shortcomings with ACME is that you can only
| use one api key per DNS provider. This is problematic if you
| want to restrict api keys to a domain, or use domains belonging
| to two different accounts. I hope Nginx will not have the same
| constraint.
| mholt wrote:
| This is one of the main reasons Caddy stopped using lego for
| ACME and I wrote our own ACME stack.
| kijin wrote:
| 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 much of the internet, just so they could get
| certificates with DNS-01. I like my DNS a bit more
| decentralized than that.
| sureglymop wrote:
| 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...
|
| https://datatracker.ietf.org/doc/html/rfc2136
| cpach wrote:
| 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.
| attentive wrote:
| Yes, ACME-DNS please - https://github.com/joohoi/acme-dns
|
| Lego supports it.
| altairprime wrote:
| 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.
| cpach wrote:
| 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.)
| 0x0000000 wrote:
| 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.
| cpach wrote:
| Perhaps I have poor imagination, but I fail to see why
| why it would matter?
| 0x0000000 wrote:
| Because nginx, as an HTTP server, could answer the query?
| Arrowmaster wrote:
| You want to build a DNS server into nginx so you can
| respond to DoH query's for the domain you are hosting on
| that nginx server?
|
| Let's ignore that DoH is a client oriented protocol and
| there's no same way to only run a DoH server without an
| underlying DNS server. How do you plan to get the first
| certificate so the query to the DoH server doesn't get
| rejected for invalid certificate?
| uncleJoe wrote:
| no need to wait:
| https://en.angie.software/angie/docs/configuration/modules/h...
|
| (angie is the nginx fork lead by original nginx developers that
| left f5)
| aoe6721 wrote:
| Switch to Angie then. It supports DNS-01 very well.
| aorth wrote:
| Oh this is exciting! Caddy's support is very convenient and it
| does a lot of other stuff right out of the box which is great.
|
| One thing keeping me from switching to Caddy in my places is
| nginx's rate limiting and geo module.
| stego-tech wrote:
| 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 a PITA and I want someone to _SOLVE IT_
| without requiring AD CAs or Yet Another Hyperspecific Appliance
| (YAHA). If your load balancer, proxy server, web server, or
| router appliance can't mint me a basic Acme certificate via
| DNS-01 challenges, then you officially suck and I will throw your
| product out for something like Caddy the first chance I get.
|
| While we're at it, can we also allow DNS-01 certs to be issued
| for intermediate authorities, allowing internally-signed
| certificates to be valid via said Intermediary? That'd solve
| like, 99% of my PKI needs in any org, ever, forever.
| 0xbadcafebee wrote:
| > 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 cert from a
| trustworthy authority. If you want a non-trustworthy
| authority... go with a custom CA. It's intentionally difficult
| to do so.
|
| > If your load balancer, proxy server, web server, or router
| appliance can't mint me a basic Acme certificate via DNS-01
| challenges, then you officially suck and I will throw your
| product out for something like Caddy the first chance I get.
|
| I mean, that's a valid ask. It will become more commonplace
| once some popular corporate offering includes it, and then all
| the competitors will adopt it so they don't leave money on the
| table. To get the first one to adopt it, be a whale of a
| customer and yell loudly that you want it, then wait 18 months.
| stego-tech wrote:
| > 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 would be a device that does a public
| DNS-01 validation for a non-wildcard certificate, thus
| granting it legitimacy. It would then crank out certificates
| for _internal devices only_ , which would be trusted via the
| Root CA but without requiring those devices to talk to the
| internet or use a wildcard certificate. In other words, some
| sort of marker or fingerprint that says "This is valid
| because I trust the root _and_ I can validate the internal
| intermediary. If I cannot see the intermediary, it is not
| valid."
|
| The thinking goes is that this would allow more certificates
| to be issued internally and easily, but without the extra
| layer of management involved with a fully bespoke internal
| CA. Would it be as secure as that? No, but it would be SMB-
| friendly and help improve general security hygiene instead of
| letting everything use HTTPS with self-signed certificate
| warnings or letting every device communicate to the internet
| for an HTTP-01 challenge.
|
| If I can get PKI to be as streamlined as the rest of my tech
| stack internally, and without forking over large sums for
| Microsoft Server licenses and CALs, I'd be a very happy
| dinosaur that's a lot less worried about tracking the myriad
| of custom cert renewals and deployments.
| everfrustrated wrote:
| Intermediates aren't a delegation mechanism as such.
| They're a way to navigate to the roots trust.
|
| The trust is always in the root itself.
|
| It's not an active directory / LDAP / tree type mechanism
| where you can say I trust things at this node level and
| below.
| 0xbadcafebee wrote:
| 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.
| cnst wrote:
| You could always switch to the Angie fork if you require the
| DNS challenge type with the wildcard domains:
|
| https://en.angie.software/angie/docs/configuration/modules/h...
| andrewmcwatters wrote:
| It seems like if you commit your NGINX config with these updates,
| you can have one less process to your deployment if you're doing
| something like: #
| https://certbot.eff.org/instructions?ws=other&os=ubuntufocal
| sudo apt-get -y install certbot # sudo certbot certonly
| --standalone ... #
| https://certbot.eff.org/docs/using.html#where-are-my-certificates
| # sudo chmod -R 0755 /etc/letsencrypt/{live,archive}
|
| So, unfortunately, this support still seems more involved than
| using certbot, but at least one less manual step is required.
|
| Example from https://github.com/andrewmcwattersandco/bootstrap-
| express
| thaumaturgy wrote:
| 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 <path-to-your-acme-
| challenge-directory>; }
|
| Dehydrated has been around for a while and is a great low-
| overhead option for http-01 renewal automation.
| andrewmcwatters wrote:
| 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, LOVE, 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
| nothrabannosir wrote:
| 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?
| ygjb wrote:
| 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!
| andrewmcwatters wrote:
| 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.
| john01dav wrote:
| It's generally easier to just deal with breaking changes,
| since writing code is faster than gaining understanding
| and breaking changes in the external api are generally
| much better documented than internals.
| dspillett wrote:
| Feel free to provide and support a "stable" branch/fork that
| meets your standards.
|
| Be the change you want to see!
|
| Edit to comment on the edit:
|
| _> Edit: Downvote me all you want_
|
| I don't generally downvote, but if I were going to I would
| not need your permission :)
|
| _> that 's reality folks, if you don't release v1.0.0, the
| interface you consume can change without you realizing it._
|
| I assume you meant "present" there rather than "consume"?
|
| Anyway, 1.0.0 is just a number. Without relevant promises and
| a track record and/or contract to back them up breaking
| changes are as likely there as with any other number. A
| "version 0.x.x" of a well used and scrutinized open source
| project is more reliable and trustworthy than something that
| has just had a 1.0.0 sticker slapped on it.
|
| Edit after more parent edits: or go with one of the other
| many versioning schemes. Maybe
| ItIsFunToWindUpEntitledDicksVer Which says "stick with 0.x
| for eternity, go on, you know you want to!".
| thaumaturgy wrote:
| 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 file.
|
| It has been one of the most reliable parts of my
| infrastructure and I have to think about it so rarely that I
| had to go dig the link out of my automation repository.
| hju22_-3 wrote:
| You've been using Dehydrated since its initial commit in
| December of 2015?
| samgranieri wrote:
| This is a good first start. One less moving part. They should
| match caddy for feature parity on this, and also add dns01
| challenges as well.
|
| I'm not using nginx these days because of this.
| ankit84 wrote:
| We have been using Caddy for many years now. Picked just
| because it has automatic cert provisioning. Caddy is really an
| easier alternative, secure out of the box.
| josegonzalez wrote:
| 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.
| ctxc wrote:
| Hey! Great to see you here.
|
| I tried dokku (and still am!) and it is so hard getting
| started.
|
| For reference, - I've used Coolify successfully where it
| required me to create a Github app to deploy my apps on pushes
| to master - I've written GH actions to build and deploy
| containers to big cloud
|
| This page is what I get if I want to achieve the same, and it's
| completely a reference book approach - I feel like I'm reading
| an encyclopedia.
| https://dokku.com/docs/deployment/methods/git/#initializing-...
|
| Contrast it with this, which is INSTANTLY useful and helps me
| deploy apps hot off the page:
| https://coolify.io/docs/knowledge-base/git/github/integratio...
|
| What I would love to see for Dokku is tutorials for popular OSS
| apps and set-objective/get-it-done style getting started
| articles. I'd LOVE an article that takes me from baremetal to a
| reverse proxy+a few popular apps. Because the value isn't in
| using Dokku, it's in using Dokku to get to that state.
|
| I'm trying to use dokku for my homeserver.
|
| Ideally I want a painless, quick way to go from "hey here's a
| repo I like" to "deployed on my machine" with Dokku. And then
| once that works, peek under the hood.
| miggy wrote:
| It seems HAProxy also added ACME/DNS-01 challenge support in
| haproxy-3.3-dev6 very recently. https://www.mail-
| archive.com/haproxy@formilux.org/msg46035.h...
| owenthejumper wrote:
| It added ACME in 3.2, the DNS challenge is coming next:
| https://www.haproxy.com/blog/announcing-haproxy-3-2#acme-pro...
| RagnarD wrote:
| After discovering Caddy, I don't use Nginx any longer. Just a
| much better development experience.
| andrewstuart wrote:
| It was this that sent me from nginx to caddy.
|
| But I'm not going back. Nginx was a real pain to configure with
| so many puzzles and surprises and foot guns.
| tialaramex wrote:
| It's good to see this, it surprised me that this didn't happen to
| basically everything, basically immediately.
|
| I figured either somehow Let's Encrypt doesn't work out, or,
| everybody bakes in ACME within 2-3 years. The idea that you can
| _buy_ software in 2025 which has TLS encryption but expects _you_
| to go sort out the certificate. It 's like if cars had to be
| refuelled periodically by taking them to a weird dedicated
| building which is not useful to anything else rather than just
| charging while you're asleep like a phone and... yeah you know
| what I get it now. You people are weird.
| zaik wrote:
| Is there a way to notify other services, if renewal has succeed?
| My XMPP server also needs to use the certificate.
| smarx007 wrote:
| When 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.
| Saris wrote:
| I assume they're complaining that it's a snap vs flatpak, not
| so much vs the distro package repos.
| giancarlostoro wrote:
| 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.
| thway15269037 wrote:
| Does nginx still lock prometheus metrics and active probing
| behind $$$$$ (literal hundreds of thousands)? Forgot third most
| important thing. I think is was re-resolving upstreams.
|
| Anyway, good luck staying competitive lol. Almost everyone I knew
| either jumped to something more saner or in process of migrating
| away.
| aoe6721 wrote:
| It was introduced long time ago in Angie fork with much better
| support.
| cnst wrote:
| Here's the docs for the Angie's version of the http_acme
| module:
|
| https://en.angie.software/angie/docs/configuration/modules/h...
|
| The original announcement of Angie ACME:
|
| _Angie, fork of Nginx, supports ACME_ -
| https://news.ycombinator.com/item?id=39838228 - March 27, 2024
| (1 comment)
|
| Per above, it looks like ACME support was released with Angie
| 1.5.0 on 2024-03-27.
|
| BTW, if you don't care about ACME, and want the original nginx,
| then there's also the freenginx fork, too:
|
| _Freenginx: Core Nginx developer announces fork_ -
| https://news.ycombinator.com/item?id=39373327 - (1131 points) -
| Feb 14, 2024 (475 comments)
| ugh123 wrote:
| 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?
| philsnow wrote:
| 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)
| placatedmayhem wrote:
| 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.
| burnt-resistor wrote:
| Yeah, 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.
| ilaksh wrote:
| 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?
| ExoticPearTree wrote:
| It 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.
| idoubtit wrote:
| A little mistake with this release: they packaged the
| ngx_http_acme_module for many Linux distributions, but "forgot"
| Debian stable. Oldstable and oldoldstable are listed in
| https://nginx.org/en/linux_packages.html (packages built today)
| but Debian 13 Trixie (released 4 days ago) is not there.
| triknomeister wrote:
| That's Debian's fault I guess
| sjmulder wrote:
| How is that? These are vendor packages
| thresh wrote:
| I'm currently working on getting the Trixie packages uploaded.
| It'll be there this week.
|
| As you've said Debian 13 was released 4 days ago - it takes
| some time to spin up the infrastructure for a new OS (and we've
| been busy with other tasks, like getting nginx-acme and 1.29.1
| out).
|
| (I work for F5)
| breadwinner wrote:
| But can it generate self-signed certificate for intranet use?
| Often on the intranet you want to encrypt traffic, to prevent
| casual snooping using Wireshark.
| metafunctor wrote:
| 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.
| arjie wrote:
| Neat, that'll be nice to have. Currently I just use certbot and
| it does a pretty damn good job. I just set the HTTP:80
| configuration and certbot will migrate it to HTTPS:443 and take
| care of the certificates and so on. For the moment, I'll probably
| stick to that till this is mature.
___________________________________________________________________
(page generated 2025-08-13 23:00 UTC)