Why curl fails while browser calls succeed?

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 which caddy exposes 443)
  • test.example.com points to 192.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.

I think you’ll want to use the --resolve option of curl for this. The reason its failing is because setting the Host header isn’t enough to have SNI be set for the TLS handshake:

https://hacksbrain.com/2018/08/27/testing-sni-enabled-servers-with-curl/

1 Like

Thank you @francislavoie - that was it indeed!

1 Like

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