Wildcard Subdomain SSL giving SSL error - ERR_SSL_PROTOCOL_ERROR

Help
1

How can I disable SSL for wildcard sub-domain ?

Whenever I add

example.com {
   ...
}

*.example.com {
    // same code as example.com above except below line
    tls off
}

*.example.com is not picked by caddy - All sub-domain gives 404 site not hosted on this interface.

but it works, when using

example.com *.example.com {
    ... code here
}

I just want to disable SSL for wild card sub-domain

Thanks

2

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.

https://caddyserver.com/docs/http-caddyfile#addresses

3

I want to disable SSL for sub-domain but want to keep SSL for main domain. Here is my Caddy file code -

example.com *.example.com {
    header / Server "Caddy Server"
    root   /var/www/html/example.com
    gzip
    proxy / localhost:3000 {
        header_upstream Host {host}
    }
    tls {
        max_certs 10
    }
}
4

You can’t configure On-Demand TLS but also disable TLS on the same site definition.

You will need to make one site definition with TLS enabled, and one site definition without TLS.

5

When I do something like this -

example.com {
    header / Server "Caddy Server"
    root   /var/www/html/example.com
    gzip
    proxy / localhost:3000 {
        header_upstream Host {host}
    }
    tls {
        max_certs 10
    }
}

*.example.com {
    header / Server "Caddy Server"
    root   /var/www/html/example.com
    gzip
    proxy / localhost:3000 {
        header_upstream Host {host}
    }
    tls off
}

http://* {
    header / Server "Caddy Server"
    root   /var/www/html/example.com
    gzip
    proxy / localhost:3000 {
        header_upstream Host {host}
    }
    tls off
}

My all sub-domain stops working.

6

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?

1 Like
7

I want middle site definition to work for port 80 - will I need to do something like this for middle site

http://*.example.com {
    header / Server "Caddy Server"
    root   /var/www/html/example.com
    gzip
    proxy / localhost:3000 {
        header_upstream Host {host}
    }
    tls off
}

First and Third works fine.

From stop working, I mean port 80 not opening - I was not sure of port 2015 earlier

8

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.

1 Like
9

Great! This works now.

Is it possible to redirect "https://*.example.com" to http://*.example.com ?

Thanks

10

I tried using this - but my caddy fails

https://*.example.com {
    redir http://{host}{uri}
}
11

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.

12

Yes, whenever I am using

tls {
    max_certs 50
}

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.

13

I am not able to find enough documentation for tls { dns cloudflare }, whenever I use that caddy fails.

I believe it needs email and API key, where to place them - can’t get enough of it.

wildcard ssl doesn’t work with caddy. It works for some sub-domain and then it stops for other. Just not sure why

14

Here’s what you need:

You will also need to set environment variables with your account credentials:
[…]
CLOUDFLARE_EMAIL, CLOUDFLARE_API_KEY

– Automatic HTTPS — Caddy Documentation

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 !)

– Automatic HTTPS — Caddy Documentation

And a bit further down:

On-Demand TLS is subject to these rate limits:

  • 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.

– Automatic HTTPS — Caddy Documentation

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.

2 Likes
15

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.