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

51–60 of 96 posts

Re: Native ACME support comes to Nginx

#51

Post by renewiltord »

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…

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.

For a bunch of tech-aware people the inability for you all here to modify your software to meet your needs is insane. As a 14 year old I was using the ck patch series to have a better (for me) scheduler in the kernel. Every other teenager could do this shit.

In my 30s I have a low friction set up where each bit of software only does one thing and it's easy for me to replicate. Teenagers can do this too.

Somehow you guys can't do either of these things. I don't get it. Are you stupid? Just don't load the module. Use stunnel. Use certbot. None of these things are disappearing. I much prefer. I much prefer. I much prefer. Christ. Never seen a userbase that moans as much about software (I moan about moaning - different thing) while being unable to do anything about it as HN.

Re: Native ACME support comes to Nginx

#52

Post by chrisweekly »

atomicnumber3 wrote: post #19
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…

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.

"surprised if less than 50% of the certs LE issues are not..."

triple-negative, too hard to parse

Re: Native ACME support comes to Nginx

#53

Post by jcgl »

throw_a_grenade wrote: post #41
nottorp wrote: post #28

Earlier quoted context omitted.

That's okay, next step is to fold both nginx and the acme client into systemd.

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

Re: Native ACME support comes to Nginx

#54

Post by 0x69420 »

throw_a_grenade wrote: post #41
nottorp wrote: post #28

Earlier quoted context omitted.

That's okay, next step is to fold both nginx and the acme client into systemd.

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.

multiple services depending on different outputs of a single acme client can be expressed, right now, in 2025, within systemd unit definitions, without deeply integrating a systemd-certd-or-whatever-as-such.

which is basically ideal, no? for all the buy-in that the systemd stapling-svchost.exe-onto-cgroups approach asks of us, at the very least we have sufficiently expressive system to do that sort of thing. where something on the machine has a notion of what wants what from what, and you can issue a command to see whether that dependency is satisfied. like. we are there. good. nice. hopefully ops guys are content to let sleeping dogs lie, right?

...right?

Re: Native ACME support comes to Nginx

#55

Post by 9dev »

devttyeu wrote: post #47
devttyeu wrote: post #43

Earlier quoted context omitted.

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.

[Unit] Description=Whatever [Service] ExecStart=/usr/local/bin/cantDoHttpSvc -bind 0.0.0.0:1234 [HTTP] Domain=https://whatever.net Endpoint=127.1:1234 Yeah this could happen one day

You know, Tailscale serve basically does this right now, but if I could skip this step and let systemd expose a local socket via HTTPS, automatically attempting to request a certificate for the hostname, with optional configuration in the socket unit file… I would kinda like that actually

Re: Native ACME support comes to Nginx

#57

Post by akagusu »

devttyeu wrote: post #47
devttyeu wrote: post #43

Earlier quoted context omitted.

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.

[Unit] Description=Whatever [Service] ExecStart=/usr/local/bin/cantDoHttpSvc -bind 0.0.0.0:1234 [HTTP] Domain=https://whatever.net Endpoint=127.1:1234 Yeah this could happen one day

I'm sure this will become a dependency of GNOME

Re: Native ACME support comes to Nginx

#59

Post by [deleted] »

jsheard wrote: post #35
lysace wrote: post #8

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

[deleted]

Re: Native ACME support comes to Nginx

#60

Post by 9dev »

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…

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 no intervention necessary, and just communicate securely with each other. And ACME is the way to enable that.

Post reply on HN