caddy: Caddy tries to get certificate for domains only in host matcher within site block

Does JSON deactivate host matcher to activate automatic HTTPS? Example:

{
	order forward_proxy before file_server
	admin off
	log {
		output file /var/log/caddy/access.log
		level ERROR
	}
	storage file_system {
		root /home/tls
	}

	auto_https off
	default_sni *.xx.yy
	cert_issuer zerossl
	acme_dns duckdns b8a33cc1-1111-2222-3333-b049bf07988f {
		override_domain zz.duckdns.org
	}

	servers unix//dev/shm/h1h2c.sock {
		listener_wrappers {
			proxy_protocol
		}
		protocols h1 h2c
	}

	servers 127.0.0.1:8443 {
		listener_wrappers {
			proxy_protocol
			tls
		}
	}
}

:80 {
	redir https://{host}{uri} permanent
}

:88 {
	bind unix//dev/shm/h1h2c.sock

	file_server {
		root /var/www/html
	}
}

:8443, *.xx.yy:8443 {
	bind 127.0.0.1

	forward_proxy {
		basic_auth user pass
		hide_ip
		hide_via
		probe_resistance
	}

	@host2 {
		host wh.xx.yy ch.xx.yy
	}
	file_server @host2 {
		root /var/www/html
	}
}

The above example has been normal before. After this master update, the automatic parameter is lost in the TLS configuration, that is, the certificate cannot be applied for *.xx.yy. If the above configuration deletes auto_https off, it is found that the background program automatically applies for a certificate for wh.xx.yy、ch.xx.yy. Based on the above example, thinking about the problem of the update: I think it is the most reasonable method to cancel the host matcher to activate automatic HTTPS. Benefit: Makes the Caddyfile well-configured. Make the host matcher flexible.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 25 (16 by maintainers)

Commits related to this issue

Most upvoted comments

@mholt After testing, the subroute method is successful, and the problem is solved: after deleting auto_https off, it will not automatically apply for a certificate for the subdomain. Thanks!

@lxhao61 Excellent!! Thank you for confirming! I will get this merged and tag 2.6.2, hopefully today. (If not, tomorrow.)

For reference, the relevant code is here:

https://github.com/caddyserver/caddy/blob/b4e28af953aa02fb44f88c155956488b1f473348/caddyconfig/httpcaddyfile/httptype.go#L1131-L1140

For the sake of cleaner JSON output, I wonder if it’d be worth keeping this logic for the most part, but wrap the site block in a subroute if a host matcher exists in the site block. Otherwise, I don’t think there’s a need to wrap in a subroute and we’d have unnecessarily-overly-nested JSON. 🤷‍♂️

I wonder if we should be putting the route in a subroute, though

Yeah that seems sensible.

Wait, the original post has been edited about a dozen times now. I’m trying to backtrack and see what I’m actually testing locally since it no longer matches what OP has above.

@lxhao61 If you could please try to avoid frequent edits it would make our troubleshooting more effective.

ok, sorry. I want to express it very accurately, so I edited it, and now I will not edit it anymore.

If you set auto_https off, then you’re telling Caddy “don’t manage certificates for me”. So don’t set that setting if you do want managed certificates.

I’m not sure I understand the intent of your config. It doesn’t make sense to me what you’re trying to do.

I strongly recommend removing that tls config by the way; let Caddy use its defaults for security parameters, so that when you upgrade, you get the best modern security.