Caddy reverse proxy to https upstream, only works with tls_insecure_skip_verify

Help
2

Howdy @Rukiri, welcome to the Caddy community.

HTTPS essentially sets out to achieve two goals:

  1. Prevent snooping by providing a platform to negotiate encryption of communication between server and client.
  2. Assure you, the client, that the server you’re talking to is legitimate and not some possibly-malicious impostor.

Both of these are way more important over the open internet than they are over your local area network. By configuring tls_insecure_skip_verify, you’re telling Caddy to go ahead with #1 but don’t worry at all about #2. Obviously this is very much throwing out one of the major benefits of HTTPS.

The reason we’re opinionated against skipping verification is because that with HTTPS still in place, users may be misled into thinking their setup is secure and trustworthy, when in fact a bad actor could try to impersonate your server and the skipped verification will not prevent this. We usually advise people to simply proxy over HTTP - within the context of a local area network where you have control over a relatively limited number of devices, insecure HTTP is usually plenty safe.

If you’d prefer not to use HTTP and want to get fully validated HTTPS working, though…

I’m guessing this error is because you’re proxying to an IP address and the certificate the upstream is presenting probably has a domain name instead.

The examples in the reverse_proxy documentation do a little more explaining, including the use of tls_server_name in order to tell Caddy what domain name it should be validating against on the upstream certificate.

Reverse proxy to an HTTPS upstream, but :warning: disable TLS verification. This is NOT RECOMMENDED, since it disables all security checks that HTTPS offers; proxying over HTTP in private networks is preferred if possible, because it avoids the false sense of security:

example.com {
	reverse_proxy 10.0.0.1:443 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

Instead you may establish trust with the upstream by explicitly trusting the upstream’s certificate, and (optionally) setting TLS-SNI to match the hostname in the upstream’s certificate:

example.com {
	reverse_proxy 10.0.0.1:443 {
		transport http {
			tls_trusted_ca_certs /path/to/cert.pem
			tls_server_name app.example.com
		}
	}
}

—https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#examples

You may not be required to use tls_trusted_ca_certs if your upstream’s certificate is publicly trusted. (It’s also been deprecated and should be tls_trust_pool instead.)

1 Like