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

41–50 of 96 posts

Re: Native ACME support comes to Nginx

#41

Post by throw_a_grenade »

nottorp wrote: post #28
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…

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.

Re: Native ACME support comes to Nginx

#42

Post by firesteelrain »

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?

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

Re: Native ACME support comes to Nginx

#43

Post by devttyeu »

nottorp wrote: post #28
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…

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

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.

Re: Native ACME support comes to Nginx

#44

Post by vsgherzi »

johnisgood wrote: post #34
rererereferred wrote: post #15

Earlier quoted context omitted.

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.

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.

Re: Native ACME support comes to Nginx

#46

Post by andmarios »

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?

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.

Re: Native ACME support comes to Nginx

#47

Post by devttyeu »

devttyeu wrote: post #43
nottorp wrote: post #28

Earlier quoted context omitted.

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

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

Re: Native ACME support comes to Nginx

#48

Post by dividuum »

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

Re: Native ACME support comes to Nginx

#49

Post by Spivak »

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.

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.

Re: Native ACME support comes to Nginx

#50

Post by Graphon1 »

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.

No love for caddyserver?
Post reply on HN