Serving both wildcard and custom domains from Caddy

(Rahul Chowdhury) #1

Hi,

I’m trying to set up Caddy for my PaaS app where users will have their blogs hosted either under a subdomain myblog.mydomain.com or directly via a custom domain name myblog.com.

My current Caddyfile has the following configuration:

:443 {
  proxy / Load Balancer IP {
    transparent
  }

  tls email address
  tls {
    ask endpoint
  }
}

This works fine for serving blogs via a custom domain. How do I serve blogs through a subdomain on my main domain, *.mydomain.com.

I tried adding another block like this before the :443 block:

*.mydomain.com {
}

However, this doesn’t work and both the subdomain and the custom domain serving fails.

What am I missing here?

(Toby Allen) #2

I’m not sure I fully understand you but I’ll try to see if I can help.

Caddy requires a fully configured block for each server. So if you wish to have :443 and *.example.com that is fine and you can have them in any order but you must provide all config in both blocks so

:443 {
  proxy / Load Balancer IP {
    transparent
  }

  tls email address
  tls {
    ask endpoint
  }
}

*.example.com {
  proxy / Load Balancer IP {
    transparent
  }

  tls email address
  tls {
    ask endpoint
  }
}

Is what is required. IF you are still haveing problems please post your full unedited caddyfile and start with the log directive caddy -log stdout and post any logs you get.

2 Likes
(Rahul Chowdhury) #3

Hey, Toby,

Thanks for the response. I didn’t leave the subdomain block empty in my actual Caddyfile, I didn’t paste it here because it was the same as my other block.

Except, it has the extra directive:

tls {
  dns cloudflare
  wildcard
}

I’ll try applying this config again and see what happens. Will update the thread accordingly.

(Matthew Fay) #4

You don’t need to add the wildcard subdirective if you’ve already got a wildcard in the site label. This subdirective is intended to be used when you have a fully qualified domain name that you want Caddy to treat as though it were a wildcard.

Adding a wildcard subdirective to a site label with a wildcard should, if I recall correctly, produce an error on startup, hence Caddy not serving either of your sites.

There’s still some ambiguity here - you say you added the extra directive, did that replace the tls directive of the original, or are you running one tls block with ask endpoint and one tls block with dns cloudflare and wildcard?

Just a reminder - even if you think it’s superfluous, posting your entire, unedited Caddyfile, and remembering to copy and paste any Caddy output such as process logs, will get you much better help faster.

1 Like
(Rahul Chowdhury) #5

I just configured my server again using what @tobya suggested and it started working for both custom domains and sub-domains.

However, the server fails while adding this block to my Caddyfile:

:443 {
  proxy / Load Balancer IP {
    transparent
  }

  tls email address
  tls {
    ask endpoint
  }
}

*.example.com {
  proxy / Load Balancer IP {
    transparent
  }

  tls email
  tls {
    dns cloudflare
  }
}

It says, Error during parsing: Unknown DNS provider by name 'cloudflare' on start-up.

I installed the Cloudflare plugin and also have my ENV variables set-up with my Cloudflare email and access key.

What might be the issue here?

I want to fetch a wildcard certificate and for that, I believe I require the dns directive.

(Matthew Fay) #6

Possibly the Cloudflare DNS provider plugin wasn’t installed as expected. I believe you have the correct configuration.

How do you run Caddy?

What’s the output of caddy -plugins?

1 Like
(Rahul Chowdhury) #7

Yes, you’re right. Cloudflare doesn’t show up in the list:

Server types:
  http

Caddyfile loaders:
  short
  flag
  default

Other plugins:
  http.basicauth
  http.bind
  http.browse
  http.errors
  http.expvar
  http.ext
  http.fastcgi
  http.gzip
  http.header
  http.index
  http.internal
  http.limits
  http.log
  http.markdown
  http.mime
  http.pprof
  http.proxy
  http.push
  http.redir
  http.request_id
  http.rewrite
  http.root
  http.status
  http.templates
  http.timeouts
  http.websocket
  on
  tls
  tls.cluster.file

I’ve added the plugin in the imports section:

lumberjack "gopkg.in/natefinch/lumberjack.v2"

        _ "github.com/mholt/caddy/caddyhttp" // plug in the HTTP server type
        // This is where other plugins get plugged in (imported)
        _ "github.com/caddyserver/dnsproviders/cloudflare"

Then, I did:

  1. Git commit
  2. go get ./...
  3. go install github.com/mholt/caddy/caddy
sudo cp $GOPATH/bin/caddy /usr/local/bin/
sudo chown root:root /usr/local/bin/caddy
sudo chmod 755 /usr/local/bin/caddy
sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

After that, I added the ENV to the caddy.service file and restarted the service.

(Matthew Fay) #8

You’re just ignoring your changes and installing stock Caddy (unless I’m mistaken…).

The latest instructions for building Caddy from source, with plugins, is here:

https://github.com/mholt/caddy/wiki/Plugging-in-Plugins-Yourself

1 Like
(Rahul Chowdhury) #9

I reinstalled the plugin and now it’s working. Subdomains are being served by a wildcard certificate.

However, there’s just one thing that’s not working. Custom domains are automatically getting redirected to HTTPs but not sub-domains.

I have to explicitly open https://sub.domain.com for it to use HTTPs. Otherwise it’s connecting via HTTP.

(Matthew Fay) #10

Huh, that’s odd. I’m like 98% sure that wildcard sites, with ambiguous scheme and Automatic HTTPS enabled, should set up a HTTP redirect listener as normal.

Easiest way to workaround that issue would be to further split *.example.com into two sites:

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

https://*.example.com {
  # site definition here!
}

Essentially recreating Automatic HTTPS’ default redirect listener behaviour.

(Rahul Chowdhury) #11

Thanks a lot. I’ll add that. :ok_hand:t2::grin:

1 Like