Reverse proxying to a local container via https

Help
1

1. The problem I’m having:

I am running a Mailu docker stack on a server (https://mailu.io) and reverse proxying to it via caddy (on baremetal, not containerised).

I would like to know an elegant solution to proxy https accesses to Mailu (which has a localhost mapped to its :443) without incurring into:

"http.log.error","msg":"x509: certificate is valid for mail.$MY.$DOMAIN, not localhost",

which I suspect is related to the fact that I have configured caddy as:

mail.$MY.$DOMAIN {
        reverse_proxy https://localhost:8443 
}

Adding tls_insecure_skip_verify will do the trick but I was wondering whether there is a cleaner / more apt way to achieve it?

Eventually the certificate provided by the container on 8443 matches with mail.$MY.$DOMAIN so not sure why localhost is being considered by caddy.

2. Error messages and/or full log output:

"http.log.error","msg":"x509: certificate is valid for mail.$MY.$DOMAIN, not localhost",

3. Caddy version:

2.6.2

4. How I installed and ran Caddy:

Standard apt package + systemctl.

a. System environment:

Debian 11

d. My complete Caddy config:

mail.$MY.$DOMAIN {
        reverse_proxy https://localhost:8443 
}
2

Howdy @spomata, I think there is indeed a cleaner way to go.

This is just a side-effect of the fact your upstream is the literal URL https://localhost:8443 so Caddy’s looking for a localhost cert.

You can specify a tls_server_name as a subdirective of your reverse_proxy, which tells Caddy what SNI to send upstream, and also what name to expect on the returned certificate in order to check it’s valid: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#tls_server_name

I will just take a sec to note here that this version is two years out-of-date and there’s a whole host of improvements and bugfixes that the Debian package maintainers haven’t opted to include, so we recommend upgrading with an up-to-date repository: https://caddyserver.com/docs/install#debian-ubuntu-raspbian

1 Like
3

Hi there, thanks for the detailed reply!

I like your solution as it’s quite neat, alternatively I was wondering whether proxying via port 80 would have been enough - however HTTPS should still be a choice hence I did what you suggested.

Re: caddy version, duly noted - I will allocate some time to change repo and upgrade to the newer version.

Thanks again,
Seb

1 Like