Catch-all configuration for unlimited custom domains?

[pagec (PC)]

1. Caddy version (caddy version):

v2.0.0

2. How I run Caddy:

a. System environment:

Ubuntu 18

d. My complete Caddyfile or JSON config:

  mydomain.net

  reverse_proxy * {
    to https://myapp.herokuapp.com

    header_up Host {http.reverse_proxy.upstream.hostport}
    header_up X-Forwarded-For {http.request.remote}
    header_up X-Real-IP {http.reverse-proxy.upstream.address}
    header_up X-Forwarded-Proto {http.request.scheme}
    header_up X-Forwarded-Port {http.request.port}
    header_up X-Forwarded-Host {http.request.host}
  }

3. The problem I’m having:

I have got a reverse proxy working that directs traffic to a Heroku app. The idea behind me trying to use Caddy in this way is to allow me to manage SSL termination using Caddy rather than relying on Heroku (which has limitations I’d like to avoid).

I have got it working for a single domain as per the configuration above. However, I would like my app to allow customers to enter their own preferred domain and point their DNS to my Caddy server. This would be an issue with my Caddy configuration, unless I edited to add every single customer domain. I don’t think I could automate this, which mean manual work and a poor customer experience.

Is there a way to configure Caddy to listen as a catch-all for all requests for domains that are mapped to my server? If this was possible, I think I will be able to make my app work as planned.

[francislavoie]

Yep, you’re looking for On-Demand TLS:

Automatic HTTPS - Caddy Documentation

Another user on the forums was setting this up as well today:

On Demand SSL on ports 80,443 with health checks?

Yayyy!! This finally worked. I appreciate it. I modified the code just a bit as follows: { storage file_system { root /mnt/efs/fs1 } on_demand_tls { ask https://api.nvssolutions.com/api/domain-checker-base } } :443 { reverse_proxy sites.nvssolutions.io:443 tls moe@nvssolutions.com { on_demand } } http://*.amazonaws.com { respond "OK!" } Can I ask one more? Now when I go to a site it doesn’t seem…

Also FYI:

header_up X-Forwarded-For {http.request.remote}
header_up X-Forwarded-Proto {http.request.scheme}

These lines are unnecessary, Caddy adds those on its own.

You can also use these shortcuts in the Caddyfile instead of the long form for placeholders:

Caddyfile Concepts - Caddy Documentation

And finally, you don’t need to use the to subdirective for `reverse_proxy, you can simplify it to this:

	reverse_proxy https://myapp.herokuapp.com {
		...
	}

[pagec (PC)]

Thanks for getting back to me. I have changed my config to this:

:80,:443 {
    reverse_proxy https://myapp.herokuapp.com {
      header_up Host {http.reverse_proxy.upstream.hostport}
      header_up X-Real-IP {http.reverse-proxy.upstream.address}
      header_up X-Forwarded-Port {http.request.port}
      header_up X-Forwarded-Host {http.request.host}
    }

    tls me@mydomain.com {
      on_demand
    }
}

I have set the A record of my custom domain (let’s say mydomain.net) to point to the IP address of my Caddy server. Now when I visit https://mydomain.net I’m seeing the following error in my Caddy server logs:

http: TLS handshake error from [my home IP]:51216: no certificate available for 'mydomain.net'
http: TLS handshake error from [my home IP]:51217: no certificate available for 'mydomain.net'
http: TLS handshake error from [my home IP]:51218: tls: client offered only unsupported versions: [301]

I have a feeling I may be missing something crucially important! Thanks for bearing with me.

[matt (Matt Holt)]

Welcome, Paige –

You need a space in :80, :443. The Caddyfile is sensitive to spaces, since they separate tokens. Then it will work. Right now, you’re only enabling on-demand for hostnames of :80,:443 which won’t work.

[pagec (PC)]

@matt

You need a space in :80, :443 . The Caddyfile is sensitive to spaces, since they separate tokens. Then it will work. Right now, you’re only enabling on-demand for hostnames of :80,:443 which won’t work.

Thanks Matt! I inserted the space and encountered this error:

run: adapting config using caddyfile: server listening on [:80] is HTTP, but attempts to configure TLS connection policies

Removing the :80 does indeed make it work though. I suppose my final question is whether I need the :80 at all? Trying to visit http://mydomain.net (not https) does seem to work regardless.

[matt (Matt Holt)]

Right, you shouldn’t need the :80. The redirects to HTTPS should be automatic.