Confused about wildcard tls

Help
1

1. Caddy version (caddy version):

v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=

2. How I run Caddy:

systemd

a. System environment:

ubuntu lts LXD container

b. Command:

n/a

c. Service/unit/compose file:

n/a

d. My complete Caddyfile or JSON config:

example.com {
	tls me@example.com {
		dns cloudflare <token>
		on_demand
	}

	respond "example.com"
}

*.internal.example.com {
	tls me@example.com {
		dns cloudflare <token>
		on_demand
	}

	respond "internal.example.com"
}

test.internal.example.com {
	respond "test test"
}

3. The problem I’m having:

From the logs, it appears that Caddy is getting a separate cert for test.internal.example.com

I want the wildcard certificate to apply to this and all other sub-subdomains.

4. Error messages and/or full log output:

Jan 20 11:09:05 web caddy[20528]: {“level”:“info”,“ts”:1611166145.5979447,“logger”:“tls.issuance.acme”,“msg”:“waiting on internal rate limiter”,“identifiers”:[“test.internal.example.com”]}
Jan 20 11:09:05 web caddy[20528]: {“level”:“info”,“ts”:1611166145.5979662,“logger”:“tls.issuance.acme”,“msg”:“done waiting on internal rate limiter”,“identifiers”:[“test.internal.example.com”]}
Jan 20 11:09:06 web caddy[20528]: {“level”:“info”,“ts”:1611166146.169499,“logger”:“tls.issuance.acme.acme_client”,“msg”:“trying to solve challenge”,“identifier”:“test.internal.example.com”,“challenge_type”:“dns-01”,“ca”:“https://acme-staging-v02.api.letsencrypt.org/directory”}
Jan 20 11:09:09 web caddy[20528]: {“level”:“info”,“ts”:1611166149.8529754,“logger”:“tls.issuance.acme.acme_client”,“msg”:“validations succeeded; finalizing order”,“order”:“https://acme-staging-v02.api.letsencrypt.org/acme/order/89898098/876876876”}
Jan 20 11:09:11 web caddy[20528]: {“level”:“info”,“ts”:1611166151.1410773,“logger”:“tls.issuance.acme.acme_client”,“msg”:“successfully downloaded available certificate chains”,“count”:2,“first_url”:“https://acme-staging-v02.api.letsencrypt.org/acme/cert/kjhkjhkjhkhkjhkjhkjhkjh”}
Jan 20 11:09:11 web caddy[20528]: {“level”:“info”,“ts”:1611166151.1414554,“logger”:“tls.obtain”,“msg”:“certificate obtained successfully”,“identifier”:“test.internal.example.com”}
Jan 20 11:09:11 web caddy[20528]: {“level”:“info”,“ts”:1611166151.141469,“logger”:“tls.obtain”,“msg”:“releasing lock”,“identifier”:“test.internal.example.com”}

5. What I already tried:

Putting the tls directive block in the test.... site block. The log output is from that iteration. Without it, Caddy tries the HTTP challenge (and fails since the address does not exist).

6. Links to relevant resources:

2

You can do this easily using the JSON config; the Caddyfile is for simple configs only and has to make some assumptions.

I recommend using caddy adapt to convert your config to JSON, then you can tweak it slightly to do what you want it to do.

1 Like
3

Or you could write your config like this:

*.internal.example.com {
	tls me@example.com {
		dns cloudflare <token>
		on_demand
	}

	@test host test.internal.example.com
	handle @test {
		respond "test test"
	}
	
	# Fallback for anything that wasn't matched by another handle block
	handle {
		respond "internal.example.com"
	}
}
2 Likes
4

@matt

I’ve looked through the json docs as well as my json config and I can’t say that I understand what needs to change to accomplish my goal.

While I appreciate you taking the time to answer any of these posts at all, I think your statement of “You can do this easily using the JSON config” is… misinformed? naive? I think it’s easy for you, since you are intimately familiar with Caddy. It is not at all obvious to me, and I don’t consider myself particularly dense.

Maybe the clarity and approach-ability of the documentation needs to be tested on enthusiast-level people who are not familiar with the project. Then again, maybe the docs are good enough for the main target audience. Again, I am not trying to be rude or ungrateful. Thank you for your time and this project.

@francislavoie

Thank you. I’ll try the handle/host route.

5

@francislavoie

I tried your suggestion of using handle with subdomains inside the wildcard block, with the same exact result as in the initial query – caddy obtains a separate certificate for the sub(sub)domain.

internal.example.com,
*.internal.example.com {
	tls me@example.com {
		dns cloudflare <token>
		on_demand
	}

	@web host web.internal.example.com
	handle @web {
		root * /srv/www/public_html
	}

	# catchall -- redirect to web
	handle {
		redir https://web.internal.example.com
	}
}

Feb 07 19:17:25 web caddy[25371]: {“level”:“info”,“ts”:1612750765.346008,“logger”:“http”,“msg”:“enabling automatic TLS certificate management”,“domains”:[“internal.example.com”,“*.internal.example.com”]}

Feb 07 19:17:45 web caddy[25354]: {“level”:“info”,“ts”:1612750665.1115987,“logger”:“tls.on_demand”,“msg”:“obtaining new certificate”,“server_name”:“internal.example.com”}
Feb 07 19:17:45 web caddy[25354]: {“level”:“info”,“ts”:1612750665.8322525,“logger”:“tls.issuance.acme.acme_client”,“msg”:“trying to solve challenge”,“identifier”:“internal.example.com”,“challenge_type”:“dns-01”,“ca”:“https://acme-v02.api.letsencrypt.org/directory”}
Feb 07 19:17:49 web caddy[25354]: {“level”:“info”,“ts”:1612750669.3285692,“logger”:“tls.issuance.acme.acme_client”,“msg”:“validations succeeded; finalizing order”,“order”:“https://acme-v02.api.letsencrypt.org/acme/order/kljlkj/lkjlkj”}
Feb 07 19:17:49 web caddy[25354]: {“level”:“info”,“ts”:1612750669.6916854,“logger”:“tls.issuance.acme.acme_client”,“msg”:“successfully downloaded available certificate chains”,“count”:2,“first_url”:“https://acme-v02.api.letsencrypt.org/acme/cert/lkjlkjlkjlkjlkjlkj”}
Feb 07 19:17:49 web caddy[25354]: {“level”:“info”,“ts”:1612750669.6931105,“logger”:“tls.obtain”,“msg”:“certificate obtained successfully”,“identifier”:“internal.example.com”}
…
Feb 07 19:18:18 web caddy[25371]: {“level”:“info”,“ts”:1612750998.7641063,“logger”:“tls.on_demand”,“msg”:“obtaining new certificate”,“server_name”:“web.internal.example.com”}
Feb 07 19:19:19 web caddy[25371]: {“level”:“info”,“ts”:1612750999.2954783,“logger”:“tls.issuance.acme.acme_client”,“msg”:“trying to solve challenge”,“identifier”:“web.internal.example.com”,“challenge_type”:“dns-01”,“ca”:“https://acme-v02.api.letsencrypt.org/directory”}
Feb 07 19:18:34 web caddy[25371]: {“level”:“info”,“ts”:1612751014.283799,“logger”:“tls.issuance.acme.acme_client”,“msg”:“validations succeeded; finalizing order”,“order”:“https://acme-v02.api.letsencrypt.org/acme/order/klkjlkj/lkjlkj”}
Feb 07 19:18:34 web caddy[25371]: {“level”:“info”,“ts”:1612751014.9957843,“logger”:“tls.issuance.acme.acme_client”,“msg”:“successfully downloaded available certificate chains”,“count”:2,“first_url”:“https://acme-v02.api.letsencrypt.org/acme/cert/lkjlklkjlkj”}
Feb 07 19:18:34 web caddy[25371]: {“level”:“info”,“ts”:1612751014.9969084,“logger”:“tls.obtain”,“msg”:“certificate obtained successfully”,“identifier”:“web.internal.example.com”}

6

When you enable on-demand TLS, that will be the result, since the only hostname it knows at the time is the actual hostname in the handshake. If you disable on-demand TLS, Caddy will have to use the hostnames in the config instead.

2 Likes
7

That was the missing piece. Thank you.

2 Likes
8

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