502 error when proxy to caddy https upstream

os: Ubuntu16.04
Caddy:0.11
nginx:1.14.1

Host A: 172.18.0.1, caddy1(reverse proxy, as front)
Host B: 172.18.0.2, caddy2(backend with https, as backend)
Host C: 172.18.0.3, nginx(backend with https and without no default_server option, as backend)

caddy1:

www.domain1.com {
  proxy / https://172.18.0.2 {
    insecure_skip_verify
    transparent
  }
  header / -Server
  tls {
    dns cloudflare
  }
}
www.domain2.com {
  proxy / https://172.18.0.3 {
    insecure_skip_verify
    transparent
  }
  header / -Server
  tls {
    dns cloudflare
  }
}

caddy2:

www.domain1.com {
  root /var/www
  index index.html
  header / -Server
  tls {
    dns cloudflare
  }
}

nginx:

server {
 listen 80 ;
 listen [::]:80;
 server_name www.domain2.com;
 root   /var/www;
 #ssl
 listen 443;
 listen [::]:443;
  .....
}

results:

visit https://www.domain1.com from caddy1, it will retrun error 502 Bad Gateway
visit https://www.domain1.com from caddy2. it works fine and return 200
visit https://www.domain2.com from caddy1 or nginx, it works fine and return 200

now, If I change caddy1:
and add host record to caddy1 hosts file

echo "172.18.0.2 www.domain1.com" > /etc/hosts

and change caddy1 Caddyfile to

www.domain1.com {
  proxy / https://www.domain1.com {
    insecure_skip_verify
    transparent
  }
  header / -Server
  tls {
    dns cloudflare
  }
}
www.domain2.com {
  proxy / https://172.18.0.3 {
    insecure_skip_verify
    transparent
  }
  header / -Server
  tls {
    dns cloudflare
  }
}

results:

visit https://www.domain1.com from caddy1 or caddy2 , it works fine and return 200
visit https://www.domain2.com from caddy1 or nginx, it works fine and return 200

so is it a bug? it only happen when backend is caddy.

Hi @renothing,

This looks like a bug of some kind. I was able to replicate it on Caddy 0.11.1 on macOS.

When I was testing, I had the front end Caddy (e.g. Caddy1) output access and error logs and recorded [ERROR 502 /] remote error: tls: internal error whenever I attempted to connect.

The back end Caddy (Caddy2) was also outputting access/error logs, but didn’t record anything until I attempted to connect directly (which worked fine).

The HTTPS certificates were valid in my testing (I also used DNS validation), and the error doesn’t occur when using HTTP instead of HTTPS.

For whatever reason, Caddy just doesn’t like proxying to Caddy over HTTPS…

Would you mind reporting this as an issue on the Caddy git repo? https://github.com/mholt/caddy/issues/new

1 Like

it’s here: https://github.com/mholt/caddy/issues/2427
but it’s closed few days ago.

Oh… I think this is very simple.

I was forced, by vocal and adamant “researchers” who could not find ways to make themselves useful, to break Caddy in issue #1303, the result is here: https://github.com/mholt/caddy/commit/79810d3d2372a583a81f5200928adb215a197732

And the behavior you’re seeing is a result of that change. Caddy no longer serves up a certificate when the SNI does not match a name on the certificates. In your setup, the Caddy in front is sending an IP address in its SNI, so Caddy on the backend is not serving up any certificate, presumably because no certificate has that IP address in it.

Edit: I misexplained it slightly: IP addresses don’t belong in SNI, so the SNI value is probably empty. Which certificate should Caddy serve up when there is no SNI?

Hmm. We need some way to specify the SNI, then, or this use case (internal reverse proxy over HTTPS) is completely shot.

Or better logic for choosing a certificate without SNI. What does nginx do in this case?

Please build Caddy from the latest commit(s) and help verify that this is fixed: https://github.com/mholt/caddy/commit/a7aeb979be5a59ae82fac0783fe54b83c7fc57fd

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