Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native ACME support comes to Nginx

letsencrypt.org

Post reply on HN
Print view View original

31–40 of 96 posts

Re: Native ACME support comes to Nginx

#31

Post by tuckerman »

muppetman wrote: post #20
atomicnumber3 wrote: post #19

Earlier quoted context omitted.

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.

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?

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.

Re: Native ACME support comes to Nginx

#32

Post by Ajedi32 »

muppetman wrote: post #12

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, thank…

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?

Re: Native ACME support comes to Nginx

#34

Post by johnisgood »

rererereferred wrote: post #15
petcat wrote: post #10

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

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.

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

Re: Native ACME support comes to Nginx

#35

Post by jsheard »

lysace wrote: post #8
endorphine wrote: post #4

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?

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.

Re: Native ACME support comes to Nginx

#36

Post by johnisgood »

jedisct1 wrote: post #33

Native, but requires Rust. No, thanks.

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.

Re: Native ACME support comes to Nginx

#40

Post by benwilber1 »

aargh_aargh wrote: post #7
preisschild wrote: post #6

Earlier quoted context omitted.

What does this offer to you vs using a tool such as certbot/cert-manager, and then just referencing the path in nginx?

One less program to install, configure, upgrade, watch vulnerabilities in, monitor.

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.
Post reply on HN