Got "hostname appears in more than one automation policy, making certificate management ambiguous" after updating to v2.4.0

[elvisw]

1. Caddy version

v2.4.0 h1:yHnnbawH2G3ZBP2mAJF4XBLnJanqhULLP/wu01Qi9Io=

2. Description

2a. What happens

This Caddyfile can work under v2.3.0, but when I update to 2.4.0, it doesn’t work anymore

Caddyfile

im.xxxx.com {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	reverse_proxy localhost:8000
}

im.xxxx.com/a273499c-5dc1-43d8-86fa-265d33b4bdab* {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	reverse_proxy localhost:20116 {
		transport http {
			versions h2c
		}
	}
}

im.xxxx.com/seafhttp* {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	uri strip_prefix seafhttp
	reverse_proxy localhost:8082
}

im.xxxx.com/media* {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	uri strip_prefix media
	root * /home/user1/seafile/seafile-server-latest/seahub/media
	file_server
}

I see similar issue #3906, but this should have been fix in v2.3.0.
So it's strange to see this happen again in v2.4.0. I guess this is a bug introduced in v2.4.0.

2b. Log output

May 11 16:07:38 im.xxxx.com caddy[1433]: {"level":"info","ts":1620720458.6414843,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
May 11 16:07:38 im.xxxx.com caddy[1433]: run: adapting config using caddyfile: hostname appears in more than one automation policy, making certificate management ambiguous: im.xxxx.com

[francislavoie]

Honestly, I think that error is accurate.

I don't recommend using path matchers in site blocks, it makes things complicated. I recommend writing your config like this instead, which is less ambiguous, and much shorter (I also took the liberty of using h2c:// and handle_path which shorten your config as well):

im.xxxx.com {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}

	handle /a273499c-5dc1-43d8-86fa-265d33b4bdab* {
		reverse_proxy h2c://localhost:20116
	}

	handle_path /seafhttp* {
		reverse_proxy localhost:8082
	}

	handle_path /media* {
		root * /home/user1/seafile/seafile-server-latest/seahub/media
		file_server
	}

	handle {
		reverse_proxy localhost:8000
	}
}

[elvisw]

This caddyfile is working well. Thank you very much!

[fr33tux]

I get the same error when I using a similar Caddyfile, but instead of path-based vhosts I have a different port for each of them.

Reusing the Caddyfile above:

https://im.xxxx.com {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	reverse_proxy localhost:8000
}

https://im.xxxx.com:8443 {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	reverse_proxy localhost:20116 {
		transport http {
			versions h2c
		}
	}
}

https://im.xxxx.com:8444 {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	uri strip_prefix seafhttp
	reverse_proxy localhost:8082
}

https://im.xxxx.com:8445 {
	tls {
		dns cloudflare xxxxxxxxxxxxxxxxxxxxx
	}
	uri strip_prefix media
	root * /home/user1/seafile/seafile-server-latest/seahub/media
	file_server
}

This used to work fine with 2.3, but raise the error above with 2.4. Is it expected? I can't think of a workaround..

[mholt]

I agree @francislavoie's suggestion is a much better Caddyfile.

However, the Caddyfile adapter should consolidate duplicate automation policies. A previous test case asserted incorrect behavior, and that's now been fixed in dbe164d.