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.
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.
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.