Automatic HTTPS takes a site label that looks like a domain name and serves it on ports 80 and 443, enables redirection of insecure requests to HTTPS, and handles the LetsEncrypt certificate acquisition.
When you use tls off, you’re disabling Automatic HTTPS, so Caddy does none of the above and serves it on the default port instead. The default port is 2015, so a standard HTTP request without this port specified will result in that error because the site is in fact not hosted on the interface that listens on port 80.
If you want to serve HTTP on port 80 instead, you can configure that by supplying the scheme or port, e.g. http://*.example.com or *.example.com:80.
The middle site definition in your Caddyfile will be serving the site on port 2015, if I’m not mistaken.
Requests for *.example.com on port 80 should be getting handled by the bottom site definition (the one for http://*), since the more specific site label doesn’t apply.
Can you elaborate at all on “stops working”? What action did you take, what result did you expect, and what happened instead, exactly?
Yes, what you’ve got there for the middle site should work. It will tell Caddy explicitly to serve that site over standard HTTP, which is port 80.
Caddy should be binding to port 80, if only to listen for requests for the other site definitions. Having port 80 not open would break Automatic HTTPS, too. If it’s still not working after changing your site labels around, that should be investigated.
You can do that, but you will likely want to secure HTTPS for those subdomains first, or people browsing to the site will receive certificate errors before getting redirected.
Since your site label matches any subdomain, you’ll need to use On-Demand TLS or a wildcard certificate. The former has been discussed in the other thread, and if you want to pursue a wildcard certificate, you’ll need to use DNS validation.
for wildcard domain SSL, I am getting SSL protocol error for some of the random sub-domain, that is why, I want to disable SSL for sub-domain completely.
Although it is not documented, you can also specify them in your Caddyfile directly:
tls {
dns cloudflare [email] [key]
}
There is a rate limit which may explain this behaviour.
Mitigating abuse: This feature is intentionally rate-limited. The max_certs property of the tls directive sets a hard limit on how many new certificates are issued this way, so that even over a long period of time, attackers cannot issue unlimited certificates and fill up your disk space. If this rate limiting as a safeguard is unacceptable in your case, you can alternatively use the ask subdirective to specify an internal URL from which Caddy can ask if a certain hostname is authorized for a certificate (Caddy’s built-in rate limits do not apply when using ask !)
At most one certificate challenge happens at a time.
After 10 certificates are successfully obtained, new certificate challenges will not happen until 10 minutes after the last successful challenge.
A name that fails a challenge will not be allowed to be attempted again for 5 minutes.
Note that rate limits are reset when the process exits. Using the -log flag is recommended, since all certificate challenges are logged. Note that these built-in rate limits do not apply if an ask URL is specified in the configuration. When using ask , your endpoint must return a 200 status code for the name in order for a certificate validation to be performed.
I would recommend thoroughly reading the Automatic HTTPS and HTTP Caddyfile docs to gain a comprehensive understanding of most of this - all the requirements are well documented within.