Upgrading from v0.9.4 and a broken Caddyfile

Help
1

We are actively using Caddy v0.9.5 and just tried switching to the latest version.

We are on a Windows machine, Caddy started but sites failed to load and displayed SSL errors.

Our current setup is as follows:

https:// {
	bind 19.162.27.139
	proxy / 10.1.2.253:1111 {
		header_upstream Host {host}
		header_upstream X-Real-IP {remote}
		header_upstream X-Forwarded-For {remote}
		header_upstream X-Forwarded-Proto {scheme}
	}
	tls { 
		max_certs 100000
	}
	redir 301 {
		if {>X-Forwarded-Proto} is http
		/  https://{host}{uri}
	}
}
api.oursite.com {
	bind 291.163.11.118
	header / Access-Control-Allow-Origin  *
	proxy / 39.52.101.75:80 {
		header_upstream Host {host}
		header_upstream X-Real-IP {remote}
		header_upstream X-Forwarded-For {remote}
		header_upstream X-Forwarded-Proto {scheme}
	}
	proxy /v2 http://192.169.81.218:2222 {
		header_upstream Host {host}
		header_upstream X-Real-IP {remote}
		header_upstream X-Forwarded-For {remote}
		header_upstream X-Forwarded-Proto {scheme}
	}
	tls { 
		max_certs 100000
		protocols tls1.0 tls1.2
	}
	redir 301 {
		if {>X-Forwarded-Proto} is http
		/  https://{host}{uri}
	}
}

I have read that TLS parameter had updates starting with v1 but our usage still seems to be compatible.

Any feedback on why such a setup would fail would be great and thanks very much.

2

The Caddyfile looks fine at a glance. Are you seeing any errors in Caddy’s logs?

What SSL errors are you seeing?

3

We serve to few thousand CNAMEs that are all pointing to our web app behind Caddy. Our app simply displays a customized interface to each CNAME and Caddy helps us to generate SSL certs for each CNAME.

Just ran the updated version with error logging and it seems like this new version doesn’t see the older certificates created, tries to create new certificates and being throttled (possibly due to trying to create lots of new certs).

Is there anything (like setting the path to certs) we must perform to be compatible with the new version?

4

Ahh, yes, the newer versions updated to the ACME v2 endpoint and changed the certificate scheme. Older Automatic HTTPS certificates from the v1 endpoint are not portable.

Additionally, the max_certs On-Demand TLS solution has a local rate limit of one certificate per ten minutes after the first ten certificates have been requisitioned. With a few thousand FQDNs, you might be waiting a while to fill out your certificate storage again.

If you can’t wait that long, or it’s critical you bring your sites back up immediately, I’d advise reverting back to your last working version of Caddy. You can then implement an ask endpoint to give to Caddy when you update again to the latest version. Unlike the max_certs solution, using ask to enable On-Demand TLS doesn’t have a local rate limit, as it’s assumed the ask endpoint will prevent abuse.

1 Like
5

Hey there Umut!

I also noticed you can replace all the header_upstream lines with a single transparent preset, which gets replaced with those for you.

Matthew’s advice is very good. Were you able to get the situation resolved?

7

Thanks so much for all the details. I’ll be checking the ask now and working on an implementation.

8

I didn’t know about transparent and will replace the others with it. Thanks a lot.

I couldn’t try the ask yet but will work on it just now :). Thanks a lot again.

1 Like
9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.