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

Nginx introduces native support for ACME protocol

blog.nginx.org

Post reply on HN
Print view View original

121–130 of 308 posts

Re: Nginx introduces native support for ACME protocol

#121

Post by jofla_net »

kijin wrote: post #68
chrismorgan wrote: post #61

Earlier quoted context omitted.

Sounds like you’re doing it wrong. I don’t know about this native support, but I’d be very surprised if it was worse than the old way, which could just have Certbot put files in a path NGINX was already serving (webroot method), and then when new certificates are done send a signal for NGINX to reload its config. There should never be any downtime.

Certbot has a "standalone" mode that occupies port 80 and serves /.well-known/ by itself. Whoever first recommended using that mode in anything other than some sort of emergency situation needs to be given a firm kick in the butt. Certbot also has a mode that mangles your apache or nginx config files in an attempt to wire up certificates to your virtual hosts. Whoever wrote the nginx integration also needs a butt kic…

Also, whoever decided that service providers were no longer autonomous to determine the expiration times of their own infrastructure's certificates should get that boot-to-the-head as well.

It is not as if they couldn't already choose (to buy) such short lifetimes already.

Authoritarianism at its finest.

Re: Nginx introduces native support for ACME protocol

#122

Post by tomku »

kijin wrote: post #68
chrismorgan wrote: post #61

Earlier quoted context omitted.

Sounds like you’re doing it wrong. I don’t know about this native support, but I’d be very surprised if it was worse than the old way, which could just have Certbot put files in a path NGINX was already serving (webroot method), and then when new certificates are done send a signal for NGINX to reload its config. There should never be any downtime.

Certbot has a "standalone" mode that occupies port 80 and serves /.well-known/ by itself. Whoever first recommended using that mode in anything other than some sort of emergency situation needs to be given a firm kick in the butt. Certbot also has a mode that mangles your apache or nginx config files in an attempt to wire up certificates to your virtual hosts. Whoever wrote the nginx integration also needs a butt kic…

Those choices and Certbot strongly encouraging snap installation was enough to get me to switch to https://go-acme.github.io/lego/, which I've been very happy with since. It's very stable and feels like it was built by people who actually operate servers.

Re: Nginx introduces native support for ACME protocol

#123

Post by everfrustrated »

stego-tech wrote: post #85
0xbadcafebee wrote: post #52

Earlier quoted context omitted.

> allowing internally-signed certificates to be valid via said Intermediary By design, nothing is allowed to delegate signing authority, because it would become an immediate compromise of everything that got delegated when your delegated authority got compromised. Since only CAs can issue certs, and CAs have to pass at least some basic security scrutiny, clients have assurance that the thing giving it a cert got said…

> If you want a non-trustworthy authority... go with a custom CA. It's intentionally difficult to do so. This is where I get rankled. In IT land, everything needs a valid certificate. The printer, the server, the hypervisor, the load balancer, the WAP’s UI, everything. That said, most things don’t require a publicly valid certificate. Perhaps Intermediate CA is the wrong phrase for what I’m looking for. Ideally it wo…

Intermediates aren't a delegation mechanism as such. They're a way to navigate to the roots trust.

The trust is always in the root itself.

It's not an active directory / LDAP / tree type mechanism where you can say I trust things at this node level and below.

Re: Nginx introduces native support for ACME protocol

#124

Post by idoubtit »

A little mistake with this release: they packaged the ngx_http_acme_module for many Linux distributions, but "forgot" Debian stable. Oldstable and oldoldstable are listed in https://nginx.org/en/linux_packages.html (packages built today) but Debian 13 Trixie (released 4 days ago) is not there.

Re: Nginx introduces native support for ACME protocol

#125

Post by triknomeister »

idoubtit wrote: post #124

A little mistake with this release: they packaged the ngx_http_acme_module for many Linux distributions, but "forgot" Debian stable. Oldstable and oldoldstable are listed in https://nginx.org/en/linux_packages.html (packages built today) but Debian 13 Trixie (released 4 days ago) is not there.

That's Debian's fault I guess

Re: Nginx introduces native support for ACME protocol

#126

Post by sjmulder »

triknomeister wrote: post #125
idoubtit wrote: post #124

A little mistake with this release: they packaged the ngx_http_acme_module for many Linux distributions, but "forgot" Debian stable. Oldstable and oldoldstable are listed in https://nginx.org/en/linux_packages.html (packages built today) but Debian 13 Trixie (released 4 days ago) is not there.

That's Debian's fault I guess

How is that? These are vendor packages

Re: Nginx introduces native support for ACME protocol

#128

Post by nodesocket »

Saris wrote: post #91
elashri wrote: post #8

Earlier quoted context omitted.

What I really like about Caddy is their better syntax. I actually use nginx (via nginx proxy manager) and Traefik but recently I did one project with Caddy and found it very nice. I might get the time to change my selfhosted setup to use Caddy in the future but probably will go with something like pangolin [1] because it provides alternative to cloudflare tunnels too. [1] https://github.com/fosrl/pangolin

Caddy does have some bizarre limitations I've run into, particularly logging with different permissions when it writes the file, so other processes like promtail can read the logs. With Caddy you cannot change them, it always writes with very restrictive permissions. I find their docs also really hard to deal with, trying to figure out something that would be super simple on Nginx can be really difficult on Caddy, if…

I use Caddy as my main reverse proxy into containers with CloudFlare based DNS let’s encrypt. The syntax is intuitive and just works. I’ve used Traefik in the past with Kubernetes and while powerful the setup and grok ability has quite a bit steeper learning curve.

Re: Nginx introduces native support for ACME protocol

#129

Post by RadiozRadioz »

reactordev wrote: post #73
samgranieri wrote: post #44

Earlier quoted context omitted.

I use dns01 in my homelab with step-ca with caddy. It's a joy to use

+1 for caddy. nginx is so 2007.

So a tool's value should be judged as inversely proportional to its age?

Re: Nginx introduces native support for ACME protocol

#130

Post by mholt »

reactordev wrote: post #109
darkwater wrote: post #92

Earlier quoted context omitted.

Caddy is just for developers that want to publish/test the thing they write. For power users or infra admins, nginx is still much more valuable. And yes, I use Caddy in my home lab and it's nice and all but it's not really flexible as nginx is.

Caddy is in use here in production. 14M requests an hour.

Where's that if I may ask?
Post reply on HN