For me it was usually that the config that I need to serve a site with TLS is quite short, there are sensible defaults and many things (e.g. websockets) just work without further declaration. That's especially important if you want to host a container that has some lacking documentation about usage of reverse proxies, as most things "just work fine" for me.
And using a simple include directive, you can even replicate 'sites-available' and 'sites-enabled' behaviour. My standard Caddyfile just sets up the log file format and location and basic Let Encrypt values. Then it includes /foo/bar/sites-available/*. Every deployment/container now has its own Caddyfile that just gets linked there.
I believe Let's Encrypt only allows wildcard certs for DNS challenges so it's not really in the scope of Nginx; but I haven't used other web servers, do they implement that?
Edit: Looked into Caddy, it seems to have a plugin system for DNS providers, that's pretty slick. I can't see that ever happening for Nginx they seem very opinionated in wanting to be unopinionated unfortunately. I'm still sad they rejected the PR to implement prefers-color-scheme for default error pages.
You can setup wild card certs with a DNS challenge using traefik. No plug-ins needed, works right out the box.
Personally, I quite prefer traefik. Its harder to use than Caddy but offers more features. Also, it uses yaml or docker labels for config. I'm not a fan of the nginx .conf format.
DNS-01 is in the pipeline at least, so hopefully we'll see that bring wildcard certs along with it.
It's nice to see this being integrated into nginx. I've been using ACME.sh for around a decade instead. It just triggers through a script on a crontab schedule grabbing a new cert via DNS-01 if necessary, then refreshing nginx to recognize the new file.
I guess Caddy has been stealing its market share
I knew there was a reason that I used Caddy all these years
For me it was usually that the config that I need to serve a site with TLS is quite short, there are sensible defaults and many things (e.g. websockets) just work without further declaration. That's especially important if you want to host a container that has some lacking documentation about usage of reverse proxies, as most things "just work fine" for me.
And using a simple include directive, you can even replicate 'sites-available' and 'sites-enabled' behaviour. My standard Caddyfile just sets up the log file format and location and basic Let Encrypt values. Then it includes
/foo/bar/sites-available/*. Every deployment/container now has its own Caddyfile that just gets linked there.Even though I've been using traefik and caddy more lately, I appreciate that nginx has finally woken up :)
No wildcard support sigh
I believe Let's Encrypt only allows wildcard certs for DNS challenges so it's not really in the scope of Nginx; but I haven't used other web servers, do they implement that?
Edit: Looked into Caddy, it seems to have a plugin system for DNS providers, that's pretty slick. I can't see that ever happening for Nginx they seem very opinionated in wanting to be unopinionated unfortunately. I'm still sad they rejected the PR to implement
prefers-color-schemefor default error pages.You can setup wild card certs with a DNS challenge using traefik. No plug-ins needed, works right out the box.
Personally, I quite prefer traefik. Its harder to use than Caddy but offers more features. Also, it uses yaml or docker labels for config. I'm not a fan of the nginx .conf format.
DNS-01 is in the pipeline at least, so hopefully we'll see that bring wildcard certs along with it.
It's nice to see this being integrated into nginx. I've been using ACME.sh for around a decade instead. It just triggers through a script on a crontab schedule grabbing a new cert via DNS-01 if necessary, then refreshing nginx to recognize the new file.
FINALLY! Caddy has been doing it for years! I still prefere caddy overall but it's nice to have as we don't always choose the stack we work with.
ACME Website Host-inator or idk, i don't know much about networking