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

241–250 of 308 posts

Re: Nginx introduces native support for ACME protocol

#241

Post by account42 »

pointlessone wrote: post #224
metafunctor wrote: post #156

I never saw it as a problem for nginx to just serve web content and let certbot handle cert renewals. Whatever happened to doing one thing well and making it composable? Fat tools that try to do everything inevitably suck at some important part.

Nginx with certbot is annoying to setup. Especially with HTTP challenge. Mostly because of a circular dependency. You need nginx to clear the challenge and once verboten gets a cert you need to reload nginx. I switched to Lego because it has out of the box support for my domain registrar so I could use DNS instead of HTTP challenge. It’s also a single go binary which is much simpler to install than certbot.

There is no circular dependency since the HTTP challenge uses unencrypted port 80 and not HTTPS. Reloading nginx config after cert updates is also not a problem as nginx can do that without any downtime.

Re: Nginx introduces native support for ACME protocol

#242

Post by account42 »

SchemaLoad wrote: post #174
metafunctor wrote: post #156

I never saw it as a problem for nginx to just serve web content and let certbot handle cert renewals. Whatever happened to doing one thing well and making it composable? Fat tools that try to do everything inevitably suck at some important part.

It's kind of annoying to set up. Last I remember certbot could try to automatically configure things for you but unless you had the most default setup it wouldn't work. Just having Nginx do everything for you seems like a better solution.

Certbot can just as easily work with a directory you have nginx set up to point .well-known/acme-challenge/ to. No automatic configuration magic needed.

Re: Nginx introduces native support for ACME protocol

#243

Post by account42 »

pointlessone wrote: post #225
stego-tech wrote: post #38

The IT Roller Coaster in two reactions: > Nginx Introduces Native Support for Acme Protocol IT: “It’s about fucking time! ” > The current preview implementation supports HTTP-01 challenges to verify the client’s domain ownership. IT: “ FUCK. Alright, domain registrar, mint me a new wildcard please, one of the leading web infrastructure providers still can’t do a basic LE DNS-01 pull in 2025. ” Seriously. PKI in IT is…

DNS challenge is complicated by the fact that every registrar has their own API. HTTP is easier for nginx because it’s a single flow and it already does HTTP. I’m sure nginx will get DNS but it’s still an open question when it will support your particular registrar or if at all.

> DNS challenge is complicated by the fact that every registrar has their own API

You can sidestep that by delegating the ACME keys to your own name server.

Re: Nginx introduces native support for ACME protocol

#244

Post by account42 »

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

The IT Roller Coaster in two reactions: > Nginx Introduces Native Support for Acme Protocol IT: “It’s about fucking time! ” > The current preview implementation supports HTTP-01 challenges to verify the client’s domain ownership. IT: “ FUCK. Alright, domain registrar, mint me a new wildcard please, one of the leading web infrastructure providers still can’t do a basic LE DNS-01 pull in 2025. ” Seriously. PKI in IT is…

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

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

Or because it would expose the web PKI for the farce it is. Some shady corporation in bumfuckistan having authority to sign certificates for .gov.uk or even just your personal website is absolutely bonkers. Certificate authority should have always been delegated just like nameserver authority is.

Re: Nginx introduces native support for ACME protocol

#245

Post by account42 »

everfrustrated wrote: post #123
stego-tech wrote: post #85

Earlier quoted context omitted.

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

But they could and IMO should be a delegation mechanism. The Name Constraints extension already exists.

Re: Nginx introduces native support for ACME protocol

#246

Post by stephenr »

kocial wrote: post #171

The problem with the big open-source companies is that they are always very late to understand and implement the most basic innovations that come out. Caddy & Traefik did it long, long ago (half a decade ago), and after half a decade, we finally have ngxin supporting it too. Great move though, finally I won't have to manually run certbot :pray:

Given that Caddy has a history that includes choices like "refuse to start if LE cannot be contacted while a valid certificate exists on disk" I'm pretty happy to keep my certificate issuance separate from a web server.

I need a tool to issue certs for a bunch of other services anyway, I don't really see how it became such a thing for people to want it embedded in their web server.

Re: Nginx introduces native support for ACME protocol

#247

Post by stephenr »

stego-tech wrote: post #38

The IT Roller Coaster in two reactions: > Nginx Introduces Native Support for Acme Protocol IT: “It’s about fucking time! ” > The current preview implementation supports HTTP-01 challenges to verify the client’s domain ownership. IT: “ FUCK. Alright, domain registrar, mint me a new wildcard please, one of the leading web infrastructure providers still can’t do a basic LE DNS-01 pull in 2025. ” Seriously. PKI in IT is…

What company that has enough infrastructure to dictate an IT Department is also only using certificates on their web servers, and thus doesn't have a standard tool for issuing/renewing/deploying certificates for *all* services that need them?

Re: Nginx introduces native support for ACME protocol

#248

Post by stephenr »

metafunctor wrote: post #156

I never saw it as a problem for nginx to just serve web content and let certbot handle cert renewals. Whatever happened to doing one thing well and making it composable? Fat tools that try to do everything inevitably suck at some important part.

I wonder about the same thing. I've come to the conclusion that it's driven a lot by Management-Ideal definition of devops: developers who end up doing OPs without sufficient knowledge or experience to do it well.

Re: Nginx introduces native support for ACME protocol

#249

Post by pointlessone »

account42 wrote: post #241
pointlessone wrote: post #224

Earlier quoted context omitted.

Nginx with certbot is annoying to setup. Especially with HTTP challenge. Mostly because of a circular dependency. You need nginx to clear the challenge and once verboten gets a cert you need to reload nginx. I switched to Lego because it has out of the box support for my domain registrar so I could use DNS instead of HTTP challenge. It’s also a single go binary which is much simpler to install than certbot.

There is no circular dependency since the HTTP challenge uses unencrypted port 80 and not HTTPS. Reloading nginx config after cert updates is also not a problem as nginx can do that without any downtime.

There’s dependency in the nginx config. You have to specify where your certs are. So you have to have a working config before you start nginx, then you need to get certs and change config with the cert/key location before you can HUP nginx. This is extremely brittle, especially if you have a new box or a setup where you regularly bring up clean nodes as that’s when you can get all sorts of unexpected things to happen. It’s much less brittle when you already have a cert and a working config and just renew the certificate but not all setups are like that. I can’t even confidently say that most are like that.

Re: Nginx introduces native support for ACME protocol

#250

Post by withinboredom »

reactordev wrote: post #177
yupyupyups wrote: post #152

Earlier quoted context omitted.

It's time for DNS providers to start supporting TSIG + key management. This is a standardized way to manipulate DNS records, and has a very granular ACL. We don't need 100s of custom APIs. https://en.m.wikipedia.org/wiki/TSIG

The whole point is to abstract that from the users so they don’t know it’s a giant flat file. Selling a line at a time for $29.99. (I joke, obviously)

Digital Ocean DNS is free (it’s the only reason I have an account there)
Post reply on HN