Reverse proxy without domain name

Help
21

As far as choosing a certificate goes, yes. If there’s no ServerName in the TLS ClientHello, then Caddy looks for a certificate with the IP address the client is connecting to. (Technically, CertMagic does this dirty work, but you get the picture.)

Edit: Not sure if still relevant, but this error:

TLS handshake error from 192.168.1.200:39088: remote error: tls: unknown certificate

just means that the browser (Chrome) rejected the ServerHello because of “unknown certificate” which is just an arbitrary message they chose to probably mean “I don’t trust this certificate” – in any case, Caddy apparently presented a cert in this case but the browser didn’t “know” it (whatever that means).

1 Like
22

…which, because Docker is port forwarding from the host to the Docker container’s IP address, is some 172.19.x.x IP…

Congratulations, everybody. The issue technically wasn’t DNS, this time! :tada:

So, basically, @dclman - I expect this would work just fine if you did this over HTTP instead OR if your server had a hostname you could browse to instead of an IP address (some kind of example.local or something).

Alternately, putting the Caddy container on the host network stack. But then, same issue - you’d have to expose Bitwarden on one of the host’s ports and probably refer to it as localhost:9999 from Caddy.

I think that’s fine - that’s just from when he added the 172.19.x.x to his Caddyfile, Caddy served a cert for it, and his browser auto rejected it the first few attempts until he manually accepted (see: “then I ERR_CERT_AUTHORITY_INVALID but can access the webpage anyway via chrome”).

1 Like
23

Cool. Mystery solved then?

You can also configure Caddy with a default_sni which it will use if the client does not specify a ServerName. In that case, it will use the name in default_sni when looking for a certificate. (Of course, the client may still reject it.)

1 Like
24

Yes! That’d be quite neat, actually. There’s a global option for it in the Caddyfile, too.

  • default_sni sets a default TLS ServerName for when clients do not use SNI in their ClientHello.

—Global options (Caddyfile) — Caddy Documentation

@dclman, instead of adding 172.19.0.4 to your list of site labels, add default_sni 192.168.1.200 to a global options block (open a braced block at the very top of your Caddyfile) and see if that solves this issue.

1 Like
25

Adding that works!! Thanks so much for all of ya’lls help! 100% couldn’t have figured that out so I’m glad i asked heh

(for reference the final Caddyfile:)

{
        default_sni 192.168.1.200
}

https://192.168.1.200:9999  {
        reverse_proxy crcc:8000
}
2 Likes
26

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