We discussed this about a month ago: https://news.ycombinator.com/item?id=44889941
Thanks! Macroexpanded:
Nginx introduces native support for ACME protocol - https://news.ycombinator.com/item?id=44889941 - Aug 2025 (298 comments)
Native ACME support comes to Nginx
81–90 of 96 posts
Re: Native ACME support comes to Nginx
#82Earlier quoted context omitted.
Unironicaly, I think having systemd-something util that would provide TLS certs for .services upon encountering specific config knob in [Service] section would be much better that having multitude uncoordinated ACME clients that will quickly burn through allowed rate limits. Even just as a courtesy to LE/ISRG's computational resources.
A systemd-certd would actually kinda slap. One cert store to rule them all for clients, a way to define certs and specify where they're supposed to be placed with automatic reload using the systemd dependency solver, a way to mount certs into services privately, a unified interface for interacting with the cert store.
So ... not only would your system take ages to boot without the internets(tm) because that's how systemd works, it will be extended in the same spirit to not boot at all if letsencrypt is down.
Sounds enterprise.
Also, you people forgot that my proposal is to also fold the http server in, and ideally all the scripting languages and all of npm just in case.
Re: Native ACME support comes to Nginx
#83I wish they listed Caddy before Traefik there - Caddy pioneered this hands-free certificate automation in a webserver.
Re: Native ACME support comes to Nginx
#84Earlier quoted context omitted.
Nginx is now owned by F5. Big, expensive and amazingly slow in terms of development. Related notice: I really enjoy using haproxy for load balancing.
See also: nginx's HTTP/3 support still being experimental, when pretty much every other server besides Apache shipped it years ago.
Yes tho the odds are anybody wanting http3 likely also using a cdn. There aren't too many cdns which support http3 back to origin. Heck most of them don't even support ipv6-only origins.
Re: Native ACME support comes to Nginx
#85Earlier quoted context omitted.
Agreed. I have had my share of compiling Rust programs, pulling in thousands of dependencies. If people think it is good practice, then well, good for them, but should not sell Rust as a safe language when it encourages such unsafe practices, especially when there are thousands of dependencies and probably all of them have their own unsafe blocks (even this ACME support does), which affect the whole codebase. I am go…
This is a problem I'm pretty invested in so let's take a look. If we add the list of dependencies from the modules this is what we get anyhow = "1.0.98" base64 = "0.22.1" bytes = "1.10.1" constcat = "0.6.1" futures-channel = "0.3.31" http = "1.3.1" http-body = "1.0.1" http-body-util = "0.1.3" http-serde = "2.1.1" hyper = { version = "1.6.0", features = ["client", "http1"] } libc = "0.2.174" nginx-sys = "0.5.0-beta" n…
I do not think it is the language to blame for it anyways. That said, I just compiled Zed with release mode and it pulled about ~2000 dependencies, I do not think that this is "normal". Perhaps it is if one is coming from npm, but come on, we should know better.
Re: Native ACME support comes to Nginx
#86Earlier quoted context omitted.
Unironicaly, I think having systemd-something util that would provide TLS certs for .services upon encountering specific config knob in [Service] section would be much better that having multitude uncoordinated ACME clients that will quickly burn through allowed rate limits. Even just as a courtesy to LE/ISRG's computational resources.
It wouldn't specifically have to be a systemd project or anything; you could make a systemd generator[0] so that you could list out certs as units in the Requires= of a unit. That'd be really neat, actually. [0] https://www.freedesktop.org/software/systemd/man/latest/syst...
I found this: https://github.com/woju/systemd-dehydrated/
It essentially creates per-domain units. However, those are timers, not services, because the underlying tool doesn't have long-running daemon, it's designed to run off cron. So I can't depend on them directly, and I also need to add multitude of dropins that will restart or reload services that use certificates (https://github.com/woju/systemd-dehydrated/blob/master/contr...). Coudn't figure out any way that would automate this better.
Re: Native ACME support comes to Nginx
#87Earlier quoted context omitted.
A systemd-certd would actually kinda slap. One cert store to rule them all for clients, a way to define certs and specify where they're supposed to be placed with automatic reload using the systemd dependency solver, a way to mount certs into services privately, a unified interface for interacting with the cert store.
So ... not only would your system take ages to boot without the internets(tm) because that's how systemd works, it will be extended in the same spirit to not boot at all if letsencrypt is down. Sounds enterprise. Also, you people forgot that my proposal is to also fold the http server in, and ideally all the scripting languages and all of npm just in case.
ExecStart=/usr/bin/python3 -m http.server
WorkingDirectory=/srv/www
?Re: Native ACME support comes to Nginx
#88Earlier quoted context omitted.
This is a problem I'm pretty invested in so let's take a look. If we add the list of dependencies from the modules this is what we get anyhow = "1.0.98" base64 = "0.22.1" bytes = "1.10.1" constcat = "0.6.1" futures-channel = "0.3.31" http = "1.3.1" http-body = "1.0.1" http-body-util = "0.1.3" http-serde = "2.1.1" hyper = { version = "1.6.0", features = ["client", "http1"] } libc = "0.2.174" nginx-sys = "0.5.0-beta" n…
I do not think it is the language to blame for it anyways. That said, I just compiled Zed with release mode and it pulled about ~2000 dependencies, I do not think that this is "normal". Perhaps it is if one is coming from npm, but come on, we should know better.
The problem is definitely real, I'd hope that as the ecosystem matures we come to better solutions. Microsoft and google are pretty heavily invested these days so I'd expect they'd be able to provide some clarity here.
I think we just need to push a culture of writing your own code for small things you're pulling in. (of course that just is pulling alot of weight :) )
I just get tired of everyone trying to burn down crates.io as an inherent evil.
Re: Native ACME support comes to Nginx
#89Earlier quoted context omitted.
Unsafe rust still enforces many of rust's rules. The only powers you get with unsafe rust are de-refrencing raw pointers, calling unsafe traits / functions, and the ability to access or modify mutable statics. You can read more about this here. https://doc.rust-lang.org/nomicon/what-unsafe-does.html Unsafe rust is definitely safer than normal C. All the unsafe keyword really means is that the compiler cannot verify t…
And an unsafe block in Rust having UB is exactly as bad as having UB in C or C++: the whole program's behavior can be altered in unexpected ways. So at its worst it's equivalent to C, but if there's no UB encountered in the unsafe block(s) then the whole program is safe, where for C you can hit UB anywhere in the program not just in annotated sections.
It's strange to me that others push the unsafe keyword as an "I told you so". Perhaps it's just the way rust presents it. Most rustacians I follow agree that Rust's power is turning unsafe things into safe wrappers for the programmer to use. Much of the std library is implemented with unsafe to make things work at all, and this isn't really a bad thing it is heavily vetted and tested.
Re: Native ACME support comes to Nginx
#90Earlier quoted context omitted.
I’m of the opposite opinion, really: Automatic TLS certificate requests are just an implementation detail of software able to advertise as accepting encrypted connections. Similarly many applications include an OAuth client that automatically takes care of requesting access tokens and refreshing them automatically, all using a discovery URI and client credentials. Lots of apps should support this automatically, with…
Why should every software need to support encrypted connections? That is a rabbit hole of complexity which can easily be implemented incorrectly, and is a security risk of its own. Instead, it would make more sense for TLS to be handled centrally by a known and trusted implementation, which proxies the communication with each backend. This is a common architecture we've used for decades. It's flexible, more secure, k…
Isn't nginx one of the de facto choices (alongside HAProxy) for such a proxy and therefore it makes sense to include an ACME client? (This might be what you already had in mind but given the top level comment of the thread we are in I wasn't sure)