WildCard Domain & SSL Support

Help
4

On-Demand TLS is not only for subdomains. It works for any domain. For example:

http://, https:// {
  redir {
    if {scheme} is HTTP
    / https://{host}{uri}
  }
  proxy / http://backend {
    transparent
  }
  tls {
    max_certs 10
  }
}

The above Caddyfile will handle any request for any site not handled by a more specific site definition in your Caddyfile (kind of like a default or catch-all vhost). It will (as long as the DNS correctly points to your Caddy) requisition a certificate from LetsEncrypt for the requested domain mid-connection and use the new certificate to satisfy the TLS requirements. Any request handled this way will be proxied to your backend, and any insecure requests will be upgraded to HTTPS, just like regular Automatic HTTPS.

“Wildcard” in the context of TLS is universally understood to refer to a wildcard certificate, which should only ever be valid at a subdomain level. No public issuer would ever sign a wildcard for *, so you have to retrieve domain-validated certificates on a request-by-request basis - hence, On-Demand TLS.

1.1.1.1 is operated by Cloudflare nowadays.

Also - LetsEncrypt does not issue certificates for IP addresses, only for publicly accessible domain names. Even through a traditional SSL issuer, you will likely find it difficult to arrange a HTTPS certificate for an IP address - they’re not very common at all.

SSL is supported in the manner you outline, but if you do want to disable SSL for your catch-all site definition, just use a catch-all site label that doesn’t include HTTPS.

http:// {
  proxy / http://backend
}

This will happen when Caddy has not been configured with the catch-all site label properly. If my above examples aren’t enough to get you up and running, feel free to post your Caddyfile and we can try to find out why this is the case.

1 Like