curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option.
In a Caddyfile with only one virtual host, either prepending http:// or appending :80 to the virtual host stops Caddy from serving any content over HTTPS (Chrome gives ERR_CONNECTION_REFUSED, curl returns curl: (7) Couldn't connect to server) - I suspect it simply stops listening on port 443.
With a Caddyfile specifying multiple virtual hosts it will allow the connection and respond with No such site at :443. It looks like Caddy serves the certificate of the first site in the Caddyfile that has TLS enabled, which will very likely not match the site you don’t want to serve HTTPS content on (resulting in the curl 60 error). I am not sure if this is intended behaviour.
Just spitballing, a possible workaround might be to enable TLS and redirect to http:// with a 302, like so:
That’s assuming the {hostonly} placeholder is correct in context (I didn’t test this!). If it’s not, and it isn’t easy to get the host sans scheme/port, you might be unable to redir the wildcard; you’d only be able to rely on
Search engines respect 302s, so that should avoid having https pages indexed. Search engines really like to see https, though. You could also consider using a robots.txt file.
Caddy does support wildcard virtual hosts with HTTPS, it refers to it as On-Demand TLS (scroll down).
You will need to set a TLS directive and specify the maximum number of certs. Caddy will then provision a new certificate for each request. It’s not true wildcard SSL, but it will work unless you have a larger number of subdomains than the LetsEncrypt rate limits.
Assuming again that the {hostonly} placeholder is correct:
Okay, so if you have a site listening on port 443, then browsers can connect to that port for any site because the listener is open. But the way your Caddyfile is set up, Caddy still won’t serve site2 on port 443 because it is not defined for that port, so you get the error, “No such site.” This is by design.
If you want to limit only site1 to being available on port 443 you can use the bind directive.
Hey @matt, just thought I’d ask if you had any thoughts on this part:
I’m not 100% sure this is exactly the case as I’ve only actually looked at one result so far… And as I understand it, you can’t serve HTTPS without at least a self-signed cert. But in my one test case it was using a cert from an unrelated site, which I’d think would be possibly undesirable behaviour.
I believe nginx has an option here, return 444, which logs the error internally and aborts the connection before negotiating with the client. Is Caddy capable of something similar?