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

91–96 of 96 posts

Re: Native ACME support comes to Nginx

#91

Post by jdboyd »

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…

Proxmox is not a hypervisor. It is a Linux distribution. As such it has a web server, kvm, zfs, and many other pieces. Maybe the acme client is built in to the web server. Maybe the acme client is built into their custom management software. Maybe they're just scripting around certbot.

I do tend to find that I need multiple services with tls on the same machine, such as a web server and RabbitMQ, or postfix and dovecot. I don't know how having every program have its own acme client would end up working out. That seems like it could be a mess. On the other hand, I have been having trouble getting them all to take updated certificates correctly without me manually restarting services after cert bots cron job does an update.

Re: Native ACME support comes to Nginx

#92

Post by imiric »

tuckerman wrote: post #90
imiric wrote: post #79

Earlier quoted context omitted.

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)

Yeah, I'm fine with web servers like nginx supporting TLS, ACME, or whatever protocol is required for encryption, since they can be used as proxies. I understood GP to have the opinion that most apps should have this support built-in, which is what I'm arguing against.

Re: Native ACME support comes to Nginx

#93

Post by banashark »

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?

Well you say that.... https://openresty.org/en/

"Real-world applications of OpenResty® range from dynamic web portals and web gateways, web application firewalls, web service platforms for mobile apps/advertising/distributed storage/data analytics, to full-fledged dynamic web applications and web sites. The hardware used to run OpenResty® also ranges from very big metals to embedded devices with very limited resources. It is not uncommon for our production users to serve billions of requests daily for millions of active users with just a handful of machines."

Re: Native ACME support comes to Nginx

#94

Post by jcgl »

throw_a_grenade wrote: post #86
jcgl wrote: post #53

Earlier quoted context omitted.

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/blo…

Well, every timer needs a service to activate. And at a cursory glance, this project has oneshot services, which is what I would expect for something like this. So your units (e.g. a webserver) would take After= and Wants=/Requires= on the given oneshot services.

This project looks neat! I might give it a try. I had never heard of dehydrated, but I don't particularly love certbot, and would certainly be willing to try.

Re: Native ACME support comes to Nginx

#95

Post by Spivak »

nottorp wrote: post #82
Spivak wrote: post #49

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

Well I mean if you configured your system in a manner that requires one of the wait-online services that's kinda on you. It's not required for anything by default.

It would be the same for certd. If you configure your system to hold up booting waiting for a cert then that's your choice but there's plenty of ways to have it not.

Re: Native ACME support comes to Nginx

#96

Post by SAI_Peregrinus »

vsgherzi wrote: post #89
SAI_Peregrinus wrote: post #80

Earlier quoted context omitted.

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.

And I agree with those programmers! I'm one of them. They're two sides of the same coin: Rust's power is allowing the programmer to write safe wrappers around unsafe code for those cases where the compiler can't prove the code is safe, and the weakness of `unsafe` is that it allows undefined behavior to be triggered. It's effectively a consequence of Rice's theorem: there can never be a program that is capable of proving all safe programs to be safe & all unsafe programs to be unsafe. So the compiler is designed to be "conservative" and reject some safe programs when it can't prove their safety. Rust added unsafe blocks to allow programmers to manually use more powerful logic than the compiler can in order to verify the safety of their code & wrappers, but in turn had to allow UB if the programmer messes up or just outright skips that proof.

Rust's `unsafe` blocks are great, and a necessary part of the language. The reason they're great is that they allow containing the code which could exhibit UB to a subset of the program, thereby making it easier to find the source of any mistakes. But they don't (and were never intended to) provide any guarantees about what happens if UB is encountered. It's no worse than C or C++'s UB, and having it in `unsafe` blocks means it's easier to notice where it could happen, but when it does happen it's also no better than C or C++'s UB.

Post reply on HN