TLS Error when sending request to IP


i have several servers with a caddy as reverseproxy. when i try to curl to the IP with a host-header i get an error. when doing the same to my servers with a nginx it works.

this also happens with “

first get the IP

;; ANSWER SECTION:        300     IN      A

now my curl:

❯ curl -k -H "Host:"
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

the same error happens when i omit the HOST-Header (using “-k” should tell curl to ignore certificate errors).

doing the same with an nginx-based server works:

curl -k -H "Host:"

Are there any options on caddy-side to support this “wrong” requests (although i think the requests with a given Host-Header are correct)? I have monitorings which first do a DNS-lookup with a given DNS-server (to check the correctness of the DNS) and then do a http-GET to the returned IP with different Host-Headers. sadly they do not work, i have to use the full DNS name for the query.

Caddy uses SNI to determine the certificate to use for the TLS handshake.

The Host header can only be read after the request has been decrypted, because it’s part of the HTTP payload, so it’s too late at that point.

That’s what TLS-SNI aims to solve, making it available in the clear during the handshake so routing decisions can be made without decrypting the data.

With curl, you can use a command like this instead:

curl -v --resolve

Obviously this is a bit redundant because already resolves to that IP address, but if you’d imagine a copy of the same server existed at a different IP, then you could do this to make the request to that copy instead.

You can use the default_sni global option, but you can only use a single domain for this, so if you’re serving multiple domains the same way, there’s no way to do it.

1 Like

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