Upgrading Reverse Proxy from 0.10.2 to 2.1.1

1. Caddy version (caddy version):

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

As a reverse proxy

a. System environment:

Ubuntu 18 LTS on EC2

b. Command:

./caddy start

d. My complete Caddyfile v 2.1.1 (v 0.10.2 Caddyfile is below):

:80 {

  rewrite * /custom{uri}
  
  reverse_proxy {
    to targetdomain.com:80
    header_up X-Custom-Domain {host}
  }
  log {
    output stdout
  }
}

:443 {

  rewrite * /custom{uri}

  reverse_proxy targetdomain.com:443 {
    header_up X-Custom-Domain {host}
  }

  log {
    output stdout
  }
  
  tls {
    on_demand
  }
}

3. The problem I’m having:

I have been using Caddy Server to auto-provision SSL certificates dynamically on all hosts and reverse proxy it to my final domain.

This is how the request has been routing on Caddy 0.10.2:
https://test.myserver.com/abchttps://targetdomain.com/custom/abc
https://alpha.charlie.com/xyzhttps://targetdomain.com/custom/xyz

CaddyFile for 0.10.2 is this:

:80 {

    root /var/www
    gzip

    proxy / http://targetdomain.com/custom {
        header_upstream X-Custom-Domain {host}
    }

}

:443 {

    root /var/www
    gzip

    tls {
        max_certs 1000
    }

    proxy / https://targetdomain.com/custom {
        header_upstream X-Custom-Domain {host}
    }

}

5. What I already tried:

I’ve tried various different Caddyfile 2.1.1 configurations but I’m not able to achieve the same results. We ask our users to point their domains to our Caddy server and generate their Let’s Encrypt certificates on-demand during the initial request.

What exactly isn’t working? You didn’t describe the behaviour you’re seeing. That config looks right to me as far as I can tell.

I recommend that you configure the on_demand_tls global options, in particular the ask directive to limit the allowed domains to only ones your server is aware of.

Figured the problem to be a missing host header:

    header_up Host {http.reverse_proxy.upstream.hostport}

Good idea on global on_demand_tls. Is it possible that before generating the SSL certificate, caddy could ping our web server and based on the JSON response, issue/decline the cert?

Yep, that’s exactly the purpose of the ask option

This one’s tricky. The ask logic requires a specific response, and does not inspect the response body.

If Caddy needs to obtain or renew a certificate during a TLS handshake, it will perform a quick HTTP request to this URL to check if it should be allowed to try to get a certificate for the name in the “domain” query string parameter, like so: ?domain=example.com. The endpoint must return a 200 OK status if a certificate is allowed; anything else will cause it to be denied. Redirects are not followed.

Modules - Caddy Documentation

This topic was automatically closed after 30 days. New replies are no longer allowed.