And, come to think of it, some additional great features would be automatic TLS certs via Let's Encrypt and maybe even being able to use a shared cache with multiple instances of nginx.
It took me almost exactly 3 minutes start to finish with letsencypt. Where 'start' was "I should stop putting that off" and typing "letsencrypt.com" into a browser, and 'finish' was nginx serving up https:// on all my domains. I'm genuinely curious what nginx could possibly do to improve the situation there.
You don't have to mess with having a .well-known always accessible on each domain, for example. Caddy does it for you and only when it's needed.
Nginx has a profit from big business that would require coordination to avoid multiple certificates. For comparison, it is worth noting that to ensure such coordination, Traefik requires an Enterprise plan and a separate agent. Such a business also often has mechanisms for storing certificates, so they do not necessarily want to integrate it into Nginx.
Still irritated that they ship it with an unprotected admin endpoint enabled by default on localhost:2019 that eats JSON and allows reconfiguration of the webserver like adding new sites that enable further attacks.
Put "{ admin off }" as a separate block in the root Caddyfile to disable it.
That said, see https://github.com/caddyserver/caddy/issues/5317, we are considering changing the default, but that would be a breaking change although it would likely be a transparent change for most users. The default that makes the most sense depends on the platform and installation method, which is why it's complicated.
Glad to hear you're considering changing the default!
It would be enough for me if Caddy generated a password (that's hard for attackers to predict) on first launch, set that in a config file it has write access to (autosave.json for example), and then required Basic auth using this password unless the configuration specified otherwise. My problem is that this endpoint is entirely unauthenticated.
We have yet to see this, but if we do see a practical demonstration, we're happy to reconsider.
The problem here is that a priviledged process (and yes, a process that has access to Port 80 and 443 is priviledged even if it doesn't run as root) gives unauthenticated control to less priviledged processes.
With good security design you don't lock things down as needed but instead start fully locked down and open up only the accesss you really need.
This. @mholt what we're arguing for is just to have secure defaults.
What's the pain?
https://doc.traefik.io/traefik/providers/docker/
(but preferring Caddy so far)
I should revisit Caddy and see how it gets on.
Well, for what it's worth, certbot is still pretty good: https://certbot.eff.org/
That said, with servers like Caddy supporting automatic TLS and even Apache httpd having built in support now with mod_md, Nginx feels more like an outlier for not supporting ACME out of the box: https://httpd.apache.org/docs/2.4/mod/mod_md.html
For my personal sites I actually use Apache because it's pretty good and has lots of modules (including OpenID Connect support for Keycloak etc.), but Nginx has always been really easy to install and setup, especially for serving static files (e.g. built front end apps) or being a basic reverse proxy.
Here's a bit more about how I use Apache: https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-...
And a little bit about some of the occasional warts of Nginx: https://blog.kronis.dev/everything%20is%20broken/nginx-confi... (though otherwise it's fine)
That said using HTTP-01 instead of DNS-01 across multiple nodes with the same hostname is needlessly complex in most cases and DNS-01 doesn't always have the best support in web servers (Apache in particular is just like: "Yeah, we can run whatever script you want, but the contents and integrating with your DNS server is up to you").
Or docker: https://eff-certbot.readthedocs.io/en/stable/install.html#ru...
There are quite a few other options besides certbot, I was just suggesting it as a "install + one liner" for adding auto renewing ssl certs to a server.
Also, there's massive advantages to having TLS issuance built into the webserver, such as proper OCSP stapling, having an active process to trigger renewals as soon as a revocation happens (hearing about it via OCSP), solving the ACME TLS-ALPN challenge without extra steps, and unique features like On-Demand TLS that many SaaS companies are relying on to provide a custom domains feature to their customers. None of those things are possible unless it's tightly integrated in the webserver.