Hi all!
As far as I know, if Caddy detecs any misconfiguration at startup, it bails out; not starting anything – understandably, that’s very natural and reasonable approach.
Is there any optional way to tell Caddy to skip misconfigured definitions and force it to start those defintions which are configured properly?
More specifically I am asking because of TLS; I have Caddy listening on two ports (80, 443), see the snippet below. If the certificate for HTTPS is not available on startup, neither of the definitions is started – more specifically Caddy exists due to unavailable certificate (see the error copy-pasted below).
:80 {
tls off # disable auto
...
}
:443 {
tls /etc/ssl/server.pem /etc/ssl/key.pem
...
}
Error during parsing: Unable to load certificate and key files for ':443': open /etc/ssl/server.pem: no such file or directory
To clariy my orignal question: is there a way to start :80 regardless to certificate for :443 not being available?
Note that I am intentionally using tls option, to disable automatic HTTPS in the first case, and to provide certificates explicitly in latter. This set up is meant to run in local network and I can’t (obviously) obtain any Let’s Encrypt certificates for such (localhost, or local IP address, etc.). The certiciate in the second definition is a custom self-signed certificate, to explain it futher.
I’ve seen other threads partially addressing similar problem, however these seem to only offer heated discussions without a solution which would be applicable to cases when tls is configured with certificates (suggestions using on-demand TLS are not applicable).
And finally I am aware of some workarounds (such as wrapping the Caddy call into a script to check if started properly, and otherwise removing all non-80 configuration and starting again) but I don’t want to follow this road if there would be an option to do the same directly in Caddy.
No, there is no method available to configure Caddy to partially start up, I’m afraid.
If this is critical requirement, you could look into using one instance for HTTP, and one instance for HTTPS. The latter may fail, but the former naturally won’t be affected by missing TLS assets on disk.
(Thinking further on it, I don’t think this will even affect HTTP validation for LetsEncrypt (if you do decide to use Automatic HTTPS anywhere). Since Caddies cooperate to solve ACME challenges on a shared filesystem, the HTTPS instance can make the request, and the HTTP-only instance will know how to complete it…)
The former isn’t necessary, since :80 is implicitly understood to be the standard HTTP port, but it’s not bad to keep there as an explicit declaration.
Personally, I prefer to use http:// as a site label instead of :80, likewise https:// instead of :443 - makes it even more obvious, and you can change the ports to nonstandard with -http-port / -https-port flags - but that’s just me.
I am actually thinking of starting the server in a form of the following – using the fact that Caddy exits due to misconfiguration. This way I could start some “fallback” configuration (e.g., a subset of the original configuration from Caddyfile).
