I’m working on an application and we want to give our users the ability to use their own domains to then route to our site. This feature currently works, but we want to add HTTPS support for it. My current setup is as follows:
There’s an EC2 instance that’s running Caddy from the abiosoft/caddy docker image. I’m trying to use that to proxy to our Load Balancer after the Caddy server handles the SSL handshake. The Caddyfile currently looks like this:
To test this, I created an A record in the DNS for a separate domain that is pointing at the IP for the Caddy EC2 instance. That IP is currently an Elastic IP setup in EC2. With this setup, right now I’m getting the following error:
This site can’t provide a secure connection
Before I spend much more time on this approach, I wanted to see if A) this is a viable way to handle this, and B) if it is, any thoughts on how to debug this error.
Yes, this is indeed a viable method, but there’s some caveats you’ll want to familiarize yourself with.
Check out the Automatic HTTPS documentation, specifically in the On-Demand section:
Mitigating abuse: This feature is intentionally rate-limited. The max_certs property of the tls directive sets a hard limit on how many new certificates are issued this way, so that even over a long period of time, attackers cannot issue unlimited certificates and fill up your disk space. If this rate limiting as a safeguard is unacceptable in your case, you can alternatively use the ask subdirective to specify an internal URL from which Caddy can ask if a certain hostname is authorized for a certificate (Caddy’s built-in rate limits do not apply when using ask !)
So if you’re doing this at any kind of large scale, you’re going to want to look at implementing an ask endpoint instead of using max_certs, or you’ll run into issues where Caddy won’t fetch your cert on demand because of the internal cooldown or the cert limit you specify has been reached.