Caddy not requesting wildcard domain

I have an app which allows users to access it via a different subdomain per account, so I require a wildcard certificate for my domain. I have configured Caddy (v2.3.0) as follows, however requests to user.mydomain.com and user2.mydomain.com etc results in specific TLS certificates being requested for these subdomains. I expected Caddy to generate a wildcard certificate for *.mydomain.com.

Am I doing this wrong, or does Caddy not work in this way?

For the time being I have replaced on_demand with a wildcard cert that I generated myself.

tls /etc/caddy/fullchain.pem /etc/caddy/privkey.pem

This is fine, but I’d rather have Caddy manage the renewal of the certificate if I can.

Here is my Caddyfile when trying to use on_demand for wildcards:

*.mydomain.com:443 {
    reverse_proxy 127.0.0.1:4567 {
      header_up Host {http.reverse_proxy.upstream.hostport}
      header_up X-Real-IP {http.reverse-proxy.upstream.address}
      header_up X-Forwarded-Port {http.request.port}
      header_up X-Forwarded-Host {http.request.host}
    }

    tls me@mydomain.com {
      on_demand
    }

    log {
      output file /var/log/caddy/access.log
    }
}

– Paige

1 Like

Actually I’ve just seen this page about DNS modules (I’m using Cloudflare):

It sounds like I need to do this to get wildcards to work?

I’ve rebuilt Caddy using the --with github.com/caddy-dns/cloudflare option and configured as follows:

*.mydomain.com:443 {
    reverse_proxy 127.0.0.1:4567 {
      header_up Host {http.reverse_proxy.upstream.hostport}
      header_up X-Real-IP {http.reverse-proxy.upstream.address}
      header_up X-Forwarded-Port {http.request.port}
      header_up X-Forwarded-Host {http.request.host}
    }

    tls me@mydomain.com {
      dns cloudflare <api-token>
      on_demand
    }

    log {
      output file /var/log/caddy/access.log
    }
}

However this isn’t working. Unique certs are still being generated for subdomains. I don’t see an error message relating to Cloudflare in the syslog (which is where the LetsEncrypt logs usually end up). Creating the API token in Cloudflare was interesting - there are many permissions. I created the token with access to DNS as per the docs:

However I am still not seeing a wildcard.

Ok I think I have found the problem which is the on_demand call in my config. If I remove this, it seems to work.

If someone with a bit more experience and knowledge could confirm that I’m doing the right thing, I’d really appreciate it!

*.mydomain.com:443 {
    reverse_proxy 127.0.0.1:4567 {
      header_up Host {http.reverse_proxy.upstream.hostport}
      header_up X-Real-IP {http.reverse-proxy.upstream.address}
      header_up X-Forwarded-Port {http.request.port}
      header_up X-Forwarded-Host {http.request.host}
    }

    tls me@mydomain.com {
      dns cloudflare <api-token>
    }

    log {
      output file /var/log/caddy/access.log
    }
}
2 Likes

You probably don’t need all this stuff. Try removing it. Caddy sets most appropriate headers automatically:

That’s correct. Setting on_demand defers certificate issuance until the TLS handshake. That feature and wildcard certificates are two sides of the same coin. It doesn’t make sense to have both enabled at the same time. Also, it’s unsafe to enable on_demand without configuring an ask endpoint as well, to prevent abuse. See the on_demand_tls global options for more detail.

2 Likes

Yes, thanks. I have this in my global config which I didn’t include above :blush:

2 Likes

For next time, it’s best if you not omit any parts of your config when asking for help. Parts that you think not to be relevant, are often actually relevant. It just makes it harder for us to help when we don’t have a clear picture of what’s going on.

This topic was automatically closed after 30 days. New replies are no longer allowed.