I run Caddy (v2) in a docker container as a proxy to other docker containers.
To fix an example, I have https://test.example.com
that is correctly displayed from a browser.
-
192.168.10.2
is the server that hosts the docker engine (and on whichcaddy
exposes443
) -
test.example.com
points to192.168.10.2
. -
caddy
then simply proxifies the call
(relevant Caddyfile
entry below)
https://test.example.com {
reverse_proxy container_running_test_app
}
As for the internal (docker network) IPs, caddy
got 172.19.0.31
and container_running_test_app
- 172.19.0.53
I then tried to access this test site from a command line:
curl -H Host:test.example.com https://192.168.10.2 -vvv
* Rebuilt URL to: https://192.168.10.2/
* Trying 192.168.10.2...
* TCP_NODELAY set
* Connected to 192.168.10.2 (192.168.10.2) port 443 (#0)
* schannel: SSL/TLS connection with 192.168.10.2 port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: using IP address, SNI is not supported by OS.
* schannel: sending initial handshake data: sending 162 bytes...
* schannel: sent initial handshake data: sent 162 bytes
* schannel: SSL/TLS connection with 192.168.10.2 port 443 (step 2/3)
* schannel: encrypted data got 7
* schannel: encrypted data buffer: offset 7 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with 192.168.10.2 port 443
* schannel: clear security context handle
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
On caddy
side, the following error log is issued (192.168.10.72
is the host I made the curl
call from):
2020/09/18 10:57:42 http: TLS handshake error from 192.168.10.72:52193: no certificate available for '172.19.0.31'
I am at loss, despite being sure that this is an obvious mistake of mine somewhere. Specifically - why is 172.19.0.31
(= caddy
container) part of the picture when it comes to SSL certificate matching?
Note: there is no doubt that caddy
works fine → a browser call on the same URL is fine.