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

261–270 of 308 posts

Re: Nginx introduces native support for ACME protocol

#261

Post by nickjj »

vivzkestrel wrote: post #190

Not gonna lie, setting up Nginx, Certbot inside docker is the biggest PITA ever. you need certificates to start the NGINX server but you need the NGINX server to issue certificates? see the problem? It is made infinitely worse by a tonne of online solutions and blog posts none of which I could ever get to work. I would really appreciate if someone has documented this extensively for docker compose. I dont want to use…

This is mostly why I run nginx outside of Docker, I've written about it here: https://nickjanetakis.com/blog/why-i-prefer-running-nginx-on...

I keep these things separate on the servers I configure:

    - Setting up PKI related things like DH Params and certs (no Docker)
    - My app (Docker)
    - Reverse proxy / TLS / etc. with nginx (no Docker)
This allows configuring a server in a way where all nginx configuration works over HTTPS and the PKI bits will either use a self-signed certificate or certbot with DNS validation depending on what you're doing. It gets around all forms of chicken / egg problems and reduces a lot of complexity.

Switching between self-signed, Let's Encrypt or 3rd party certs is a matter of updating 1 symlink since nginx is configured to read the destination. This makes things easy to test and adds a level of disaster recovery / reliability that helps me sleep at night.

This combo has been running strong since all of these tools were available. Before Let's Encrypt was available I did the same thing, except I used 3rd party certs.

Re: Nginx introduces native support for ACME protocol

#262

Post by dizhn »

pgug wrote: post #184
kstrauser wrote: post #17

Earlier quoted context omitted.

I agree. That, and the sane defaults are almost always nearly perfect for me. Here is the entire configuration for a TLS-enabled HTTP/{1.1,2,3} static server: something.example.com { root * /var/www/something.example.com file_server } That's the whole thing. Here's the setup of a WordPress site with all the above, plus PHP, plus compression: php.example.com { root * /var/www/wordpress encode php_fastcgi unix//run/php…

I find the documentation for the syntax to be a bit lacking if you want to do anything that isn't very basic and how they want you to do it. For example, I want to use a wildcard certificate for my internal services to hide service names from certificate transparency logs, and I can't get the syntax working. Chatgpt and gemini also couldn't.

This here is how it's done, where you have a wildcard dns entry for subdomains of secret.domain.com.

{ acme_dns cloudflare oWN-HR__kxRoDhrixaQbI6M0uwS4bfXub4g4xia2 debug }

*.secret.domain.com {

        @sso host sso.secret.domain.com
        handle @sso {
                reverse_proxy 192.168.200.4:9000
        }

        @adguard host adguard.secret.domain.com
        handle @adguard {
                reverse_proxy 192.168.200.4:9000
        }


        @forge host     forge.secret.domain.com
        handle @forge {
                reverse_proxy http://forgejo:3000
        }

        # respond to whatever doesn't match
        handle {
                respond "Wildcard subdomain does not have a web configuration!"
        }

        handle_errors {
                respond "Error {err.status_code} {err.status_text}"
        }
}

Re: Nginx introduces native support for ACME protocol

#263

Post by [deleted] »

Saris wrote: post #106
francislavoie wrote: post #96

Earlier quoted context omitted.

Actually, you can set the permissions for log files now. See https://caddyserver.com/docs/caddyfile/directives/log#file

Oh good to know! Do you know if Caddy can self update or if is there some other easy method? Manually doing it to get the cloudflare plugin is a pain.

[deleted]

Re: Nginx introduces native support for ACME protocol

#264

Post by dizhn »

francislavoie wrote: post #107
Saris wrote: post #106

Earlier quoted context omitted.

Oh good to know! Do you know if Caddy can self update or if is there some other easy method? Manually doing it to get the cloudflare plugin is a pain.

No, you have to build Caddy with plugins. We provide xcaddy to make it easy. Sign up for notifications on github for releases, and just write yourself a tiny bash script to build the binary with xcaddy, and restart the service. You could potentially do a thing where you hook into apt to trigger your script after Caddy's deb package version changes, idk. But it's up to you to handle.

I am wondering why you said "no" to the self update thing.

https://caddyserver.com/docs/command-line#caddy-upgrade

Re: Nginx introduces native support for ACME protocol

#267

Post by francislavoie »

dizhn wrote: post #264
francislavoie wrote: post #107

Earlier quoted context omitted.

No, you have to build Caddy with plugins. We provide xcaddy to make it easy. Sign up for notifications on github for releases, and just write yourself a tiny bash script to build the binary with xcaddy, and restart the service. You could potentially do a thing where you hook into apt to trigger your script after Caddy's deb package version changes, idk. But it's up to you to handle.

I am wondering why you said "no" to the self update thing. https://caddyserver.com/docs/command-line#caddy-upgrade

Because that's not automated, it's a manual command and uses caddyserver.com resources (relatively low powered cloud VMs) with no uptime guarantees. It _should not_ be used in automation scenarios, only for quick manual personal use scenarios.

Re: Nginx introduces native support for ACME protocol

#268

Post by reactordev »

reactordev wrote: post #175
mholt wrote: post #160

Earlier quoted context omitted.

Oooh. Can you tell me more about this?

In case people are wondering, this is the author of Caddy. He’s curious where it’s being used outside of home labs and in small shops. Matt, it’s fantastic software and will only get better as go improves. I used it in a proxy setup for ingress to kubernetes that’s overlayed across multiple clouds - for the government (prior admin, this admin killed it). I can’t tell you more information than that. Other than it goes…

I almost forgot. Matt. We added a little sugar to Caddy for our cluster. Hashicorp's memberlist. So we can sync the records. It worked great. Sadly, I can't share it but it's rather trivial to implement.

Re: Nginx introduces native support for ACME protocol

#269

Post by tgv »

dekobon wrote: post #83
tgv wrote: post #57

Earlier quoted context omitted.

I switched over to caddy recently. Nginx' non-information about the http 1 desync problem drove me over. I'm not going to wait for something stupid to happen or an auditor ask me questions nginx doesn't answer. Caddy is really easier than nginx. For starters, I now have templates that cover the main services and their test services, and the special service that runs for an education institution. Logging is better. Ce…

I did a google search for the desync problem and found this page: https://my.f5.com/manage/s/article/K30341203 This type of thing is out of my realm of expertise. What information would you want to see about the problem? What would be helpful?

A simple statement by the maintainers of nginx stating how to configure so that a desync attack fails. That would have been helpful. Especially since the people behind the desync attack claim nginx is not invulnerable.

I've got no idea who F5 is. They seem legit, but that page didn't show up in my DDG search. But it's too late now. Water under the bridge.

Re: Nginx introduces native support for ACME protocol

#270

Post by everfrustrated »

account42 wrote: post #245
everfrustrated wrote: post #123

Earlier quoted context omitted.

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.

The trouble is the constraint mechanism is outside of the inherent chain of trust logic and is checked using application level logic.

So you have to modify all potential clients for this constraint to be enforced. So it's effectively worthless as there is no way to roll it out in any meaningful sense.

Post reply on HN