This idea we seem to have moved towards where every applications ALSO includes their own ACME support really annoys me actually. I much prefer the idea that there's well written clients who's job it is to do the ACME handling.
Is my Postfix mailserver soon going to have an ACME shoehorned in? I've already seen GitHub issues for AdGuardHome (a DNS server that supports blocklists) to have an ACME client built in, thankfully thus far ignored.
Proxmox (a VM Hypervisor!) has an ACME Client built in.
I realise of course the inclusion of an ACME client in a product doesn't mean I need to use their implementation, I'm free to keep using my own independant client. But it seems to me adding ACME clients to everything is going to cause those projects more PRs, more baggage to drag forward etc. And confusion for users as now there's multiple places they could/should be generating certificates.
Anyway, grumpy old man rant over. It just seems Zawinski's Law "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." can be replaced these days with MuppetMan's law of "Every program attempts to expand until it can issue ACME certificates."
nottorp · 44m ago
That's okay, next step is to fold both nginx and the acme client into systemd.
devttyeu · 14m ago
Careful posting systemd satire here, there is a high likelihood that your comment becomes the reason this feature gets built and PRed by someone bored enough to also read HN comment section.
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.
Spivak · 3m ago
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.
EvanAnderson · 45m ago
I'm with you on this. I run my ACME clients as least-privileged standalone applications.
On a machine where you're only running a webserver I suppose having Nginx do it the ACME renewal makes sense.
On many of the machines I support I also need certificates for other services, too. In many cases I also have to distribute the certificate to multiple machines.
I find it easy to manage and troubleshoot a single application handling the ACME process. I can't imagine having multiple logs to review and monitor would be easier.
oliwarner · 43m ago
The idea that the thing that needs the certificate, gets the certificate doesn't seem that perverse to me. The interface/port-bound httpd needs to known what domains it's serving, what certificates it's using.
Automating this is pure benefit to those that want it, and a non-issue to those who don't — just don't use it.
renewiltord · 1m ago
You just don't load the module and use certbot and that will work which is what I'm doing. People get carried away with this stuff. The software is quite modular. It's fine for people to simplify it.
atomicnumber3 · 54m ago
I personally think nginx is the kind of project I'd allow to have its own acme client. It's extremely extremely widely used software and I would be surprised if less than 50% of the certs LE issues are not exclusively served via nginx.
Now if Jenkins adds acme support then yes I'll say maybe that one is too far.
chrisweekly · 58s ago
"surprised if less than 50% of the certs LE issues are not..."
triple-negative, too hard to parse
muppetman · 50m ago
But it's a webserver. I'm sure it farms out sending emails from forms it serves, I doubt it has a PHP library built in, surely it farms that out to php-fpm? It doesn't have a REDIS library or NodeJS built in. Why's ACME different?
tuckerman · 42m ago
I get what you are saying but surely obtaining a certificate is much closer to being considered a core part of a web server related to transport, especially in 2025 when browsers throw up "doesn’t support a secure connection with HTTPS" messages left and right, than those other examples.
I think there is also clearly demand: caddy is very well liked and often recommended for hobbyists and I think a huge part of that is the built in certificate management.
andmarios · 9m ago
Nginx (and Apache, etc) is not just a web server; it is also a reverse proxy, a TLS termination proxy, a load balancer, etc.
The key service here is "TLS termination proxy", so being able to issue certificates automatically was pretty high on the wish list.
dividuum · 7m ago
Well, it already has, among a ton of other modules, a memcached and a JavaScript module (njs), so you’re actually not that far off. An optional ACME module sounds fitting.
firesteelrain · 18m ago
To your point, we use Venafi and it has clients that act as orchestrators to deploy the new cert and restart the web service. Webservice itself doesn’t need to be ACME aware.
Venafi supports ACME protocol so it can be the ACME server like Let’s Encrypt
I am speaking purely on prem non internet connect scenario
Ajedi32 · 39m ago
It makes sense to me. If an application needs a signed certificate to function properly, why shouldn't it include code to obtain that certificate automatically when possible?
Maybe if there were OS level features for doing the same thing you could argue the applications should call out to those instead, but at least on Linux that's not really the case. Why should admins need to install and configure a separate application just to get basic functionality working?
petcat · 1h ago
> the popular open source web server NGINX announced support for ACME with their official ngx_http_acme module (implemented with memory safe Rust code!).
Why even bother calling out that it's written in "memory safe Rust code" when the code itself is absolutely riddled with unsafe {} everywhere.
It seems to me that it's written in memory unsafe Rust code.
ninkendo · 48m ago
Looks like the only unsafe parts are the parts which interop with the rest of the nginx codebase (marshalling pointers, calling various functions in nginx_sys, etc.) Rust cannot guarantee this external C stuff adheres to the necessary invariants, hence it must be marked unsafe.
I don't see a way to integrate rust as a plugin into a C codebase without some level of unsafe usage like this.
benwilber1 · 48m ago
I think the nginx-sys Rust bindings are still pretty new and raw. I've experimented with them before and have given up because of the lack of a polished, safe, Rust API.
Right now you're pretty much stuck casting pointers to and from C land if you want to write a native nginx module in Rust. I'm sure it will get better in the future.
rererereferred · 57m ago
People like bragging/advertising about their language of choice. Maybe others who like the language will get interested in collaborating, or employers who need developers for that language might get in contact with them.
Also, unsafe rust is still safer than C.
pjmlp · 43m ago
Actually it isn't, because there are a few gotchas.
Unsafe Rust, like unsafe code blocks in any language that offers them, should be kept to the bare minimum, as building blocks.
johnisgood · 37m ago
> Also, unsafe rust is still safer than C.
I highly doubt that, and developers of Rust have confirmed here on HN that when it comes to unsafe code within a codebase, it is not just the unsafe blocks that are affected, the whole codebase is affected by that.
vsgherzi · 11m ago
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 the behavior of the code it's up to the programmer. This is for cases where 1. the programmer knows more than the compiler 2. we're interacting with hardware or FFI.
When rust developers say unsafe effects the whole codebase what they mean is that UB in unsafe code could break guarantees about the whole program (even the safe parts). Just because something is unsafe dosen't inherently mean it's going to break everything it just needs more care when writing and reviewing just as C and C++ does.
KyleBerezin · 1h ago
Hey, I just decided to run a DNS server and a couple of web services on my lan from a raspberry pi over the weekend. I used Nginx for the reverse proxy so all of the services could be addressable without port numbers. It was very easy to set up, it's funny how when you learn something new, you start seeing it all over the place.
Congratulations to the folks involved. I'm sure this wasn't a trivial lift. And the improvement to free security posture is a net positive for our community.
I have moved most of my personal stuff to caddy, but I look forward to testing out the new release for a future project and learning about the differences in the offerings.
Thanks for this!
No comments yet
endorphine · 1h ago
What took them so long? Honest question.
I'd expect nginx to have this years ago. Is that so hard to implement for some reason?
aaronax · 1h ago
Slow adoption of ACME by corporate customers that pay the bills. Must be a bigger effort than one would initially think, too.
lysace · 1h ago
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.
Graphon1 · 1m ago
No love for caddyserver?
senko · 1h ago
Looks like haproxy also doesn't support it natively.
(unless I'm googlin' it wrong - all info points to using with acme.sh)
jsheard · 36m ago
See also: nginx's HTTP/3 support still being experimental, when pretty much every other server besides Apache shipped it years ago.
preisschild · 1h ago
What does this offer to you vs using a tool such as certbot/cert-manager, and then just referencing the path in nginx?
aargh_aargh · 1h ago
One less program to install, configure, upgrade, watch vulnerabilities in, monitor.
benwilber1 · 24m ago
All of those things also apply to this module since it's an extra module that you have to install separate. It's not included with the nginx base distribution. You have to configure it specifically, you have to monitor it. You have to upgrade and watch for vulnerabilities.
esher · 32m ago
Will that make local development setup easier? Like creating some certs on the fly?
mark_mart · 47m ago
Does this mean we don’t need to use certbot?
jaas · 44m ago
If you are using Nginx, then likely yes.
jedisct1 · 37m ago
Native, but requires Rust. No, thanks.
johnisgood · 33m ago
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 going to keep using certbot. No reason to switch.
aakkaakk · 58m ago
Be aware, nginx is developed by a Russian.
themafia · 11m ago
The "cold war" was one of the dumbest features of our world over the past century.
It's amazing to me that people are still addicted to it.
petcat · 56m ago
nginx has been owned and developed by an American company for a long time...
No comments yet
rererereferred · 55m ago
I own my copy of the code.
TiredOfLife · 44m ago
The last Russian quite loudly stopped working on it and released a fork
I realise of course the inclusion of an ACME client in a product doesn't mean I need to use their implementation, I'm free to keep using my own independant client. But it seems to me adding ACME clients to everything is going to cause those projects more PRs, more baggage to drag forward etc. And confusion for users as now there's multiple places they could/should be generating certificates.
Anyway, grumpy old man rant over. It just seems Zawinski's Law "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." can be replaced these days with MuppetMan's law of "Every program attempts to expand until it can issue ACME certificates."
On a machine where you're only running a webserver I suppose having Nginx do it the ACME renewal makes sense.
On many of the machines I support I also need certificates for other services, too. In many cases I also have to distribute the certificate to multiple machines.
I find it easy to manage and troubleshoot a single application handling the ACME process. I can't imagine having multiple logs to review and monitor would be easier.
Automating this is pure benefit to those that want it, and a non-issue to those who don't — just don't use it.
Now if Jenkins adds acme support then yes I'll say maybe that one is too far.
triple-negative, too hard to parse
I think there is also clearly demand: caddy is very well liked and often recommended for hobbyists and I think a huge part of that is the built in certificate management.
The key service here is "TLS termination proxy", so being able to issue certificates automatically was pretty high on the wish list.
Venafi supports ACME protocol so it can be the ACME server like Let’s Encrypt
I am speaking purely on prem non internet connect scenario
Maybe if there were OS level features for doing the same thing you could argue the applications should call out to those instead, but at least on Linux that's not really the case. Why should admins need to install and configure a separate application just to get basic functionality working?
Why even bother calling out that it's written in "memory safe Rust code" when the code itself is absolutely riddled with unsafe {} everywhere.
It seems to me that it's written in memory unsafe Rust code.
I don't see a way to integrate rust as a plugin into a C codebase without some level of unsafe usage like this.
Right now you're pretty much stuck casting pointers to and from C land if you want to write a native nginx module in Rust. I'm sure it will get better in the future.
Also, unsafe rust is still safer than C.
Unsafe Rust, like unsafe code blocks in any language that offers them, should be kept to the bare minimum, as building blocks.
I highly doubt that, and developers of Rust have confirmed here on HN that when it comes to unsafe code within a codebase, it is not just the unsafe blocks that are affected, the whole codebase is affected by that.
Unsafe rust is definitely safer than normal C. All the unsafe keyword really means is that the compiler cannot verify the behavior of the code it's up to the programmer. This is for cases where 1. the programmer knows more than the compiler 2. we're interacting with hardware or FFI.
When rust developers say unsafe effects the whole codebase what they mean is that UB in unsafe code could break guarantees about the whole program (even the safe parts). Just because something is unsafe dosen't inherently mean it's going to break everything it just needs more care when writing and reviewing just as C and C++ does.
I have moved most of my personal stuff to caddy, but I look forward to testing out the new release for a future project and learning about the differences in the offerings.
Thanks for this!
No comments yet
I'd expect nginx to have this years ago. Is that so hard to implement for some reason?
Related notice: I really enjoy using haproxy for load balancing.
(unless I'm googlin' it wrong - all info points to using with acme.sh)
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 going to keep using certbot. No reason to switch.
It's amazing to me that people are still addicted to it.
No comments yet