Caddyfile for subdomains + domains mapping

I’m super new to Caddy and just finished reading: Serving tens of thousands of domains over HTTPS with Caddy

I wish to have my multi-tenant site support:

  • https://mydomain.com
  • https://<user-created-subdomains>.mydomain.com
  • https://<user-subdomain>.userdomain.com
  • https://userdomain.com

… all running my application as backend.

I’m reading and re-reading the docs; but I think I’m still not comfortable with Caddyfile.

My existing Caddyfile -

{
    on_demand_tls {
        ask      https://my-custom-endpoint/
        interval 2m
        burst    5
    }
}

https://

tls {
    on_demand
}
reverse_proxy localhost:9000

mydomain.com
root * /var/www/html
php_fastcgi unix//run/php/php7.4-fpm.sock
file_server

Am I even doing this right? Would appreciate help.

CaddyServer Version: 2.3.0
OS: uBuntu 20.04 (Digital Ocean Droplet)

If you have more than one site to serve, you must use { } braces to wrap each site.

But otherwise, yep that’s correct.

2 Likes

Thanks, @francislavoie . However, it’s still confusing. I checked Caddyfile Directives — Caddy Documentation for Caddy V2); and there’s no directive https:// mentioned.
Here’s my Caddyfile (Not a production server. Just a test server to figure out how Caddy works) -

superdomain.com

root * /var/www/html

php_fastcgi unix//run/php/php8.0-fpm.sock

https://

tls {
    on_demand
}

file_server

Here’s the error I’m getting upon running caddy reload

2021/01/31 10:52:35.790	INFO	using adjacent Caddyfile
reload: adapting config using caddyfile: Caddyfile:7: unrecognized directive: https://

I’m following the documentation; but it looks like the documentation makes lot of assumptions about user’s knowledge about Caddyfile.

Can someone help figure out how to achieve what I’m trying to achieve?

Update: I’m not sure but I can’t get this to work. Here’s my latest attempt after reading through multiple docs:-

:443 {
root * /var/www/html
php_fastcgi unix//run/php/php8.0-fpm.sock
file_server
}

*.mydomain.com {
root * /var/www/html
php_fastcgi unix//run/php/php8.0-fpm.sock
file_server
}

I was hoping that this would allow me to have https://mydomain.com and https://<any-subdomain>.mydomain.com delivered over HTTPS. But that’s not the case.

I’ve even tried replacing :443 directly with mydomain.com but it doesn’t work. Browser throws ERR_SSL_PROTOCOL_ERROR.

I thought Caddyfile would be easy to write; but this is proving to be a nightmare :frowning:

https:// is not a directive, it’s a site address. Please review the page I linked, from the top.

Yeah, found out that https:// is an address. However, I’m still not able to get this to work. Here’s my latest attempt:

mydomain.com, *.mydomain.com {
    root * /var/www/html
    php_fastcgi unix//run/php/php8.0-fpm.sock
    file_server
}

This configuration works only for mydomain.com but not for <subdomain>.mydomain.com. What exactly am I missing out on?

What do you mean by “not working”? i.e. What is a curl command and its output?

I didn’t use curl. I added that configuration to Caddyfile and ran caddy reload. I then visited https://mydomain.com with Chrome and it worked. However https://subd.mydomain.com threw ERR_SSL_PROTOCOL_ERROR error.

PS: My sincere apologies if I’m not testing this the right way. I’m trying to achieve what you described in Serving tens of thousands of domains over HTTPS with Caddy .

It’d have helped a lot if complete Caddyfile configuration was available. I’ve spent ~2 days trying to figure this out.

I understand, but I’m asking you to so we can see more diagnostic information. Browsers do all sorts of weird things, and it’s why, in our help template which you ignored, we ask people to demonstrate the problem with curl. It avoids all the browser-induced side-effects and gives us more information to be helpful to you, rather than wasting both sides’ time. (curl -v to be specific)

The missing help template also asks for Caddy logs, and for a good reason: with curl in verbose mode and Caddy logs, we can often piece together the problem right away.

So, I can only guess. I assume it’s because you are trying to serve a wildcard domain and Caddy can’t procure a certificate. But I am not sure what your whole config looks like now. If it’s just what you posted, then it won’t have a certificate unless you control the domain mydomain.com. See, our template also asks not to redact domain names because we need that information to help you.

Just to be clear, that is an advanced topic and you’ll need to know the basics of Caddy first, like how to write a Caddyfile and how automatic HTTPS works, etc. The official documentation we’ve linked to goes into detail about all that. Especially for on-demand TLS, which is a functionality that only Caddy offers. In fact, it’s a feature so advanced that large companies have invested tens or hundreds of thousands of dollars into other, more complex software solutions to do this very thing: yet it’s free and simple with Caddy.

If you’re just serving subdomains for your domain name, though, don’t use on-demand TLS. Use a single wildcard certificate instead.

Yes, it would be nice if all our work was done for us. :slight_smile: But that’s not how this works, because everyone’s config is different. 2 days isn’t much time for a beginner – I’d suggest keep working at it, reading and experimenting, and you will eventually become expert at how everything works. There’s a lot at play, and while Caddy makes it simple, you have to know how to use your tools and what’s going on with the rest of the computer and the network, etc.

Anyway, I’m sorry if you’re getting frustrated. If you can provide more information (logs, curl output, full and unredacted config, etc.) we can help you better.

2 Likes

@matt - my apologies. You’re right - I’m looking for very advanced configuration. I should have followed the template. I’ll create another thread with all the required information and I hope to find some help.

Thank you for all the wonderful work you’ve been doing with Caddy! :+1:t4:

1 Like

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