Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS does not work on NATed IPv4 literal #6344

Open
ledlamp opened this issue May 27, 2024 · 1 comment
Open

TLS does not work on NATed IPv4 literal #6344

ledlamp opened this issue May 27, 2024 · 1 comment

Comments

@ledlamp
Copy link

ledlamp commented May 27, 2024

caddy version v2.7.6

Host has private IP 10.0.0.79 and public IP 129.159.139.0 NAT forwarded (Oracle Cloud).

This works as expected:

10.0.0.79 {
        tls internal
        respond "ok"
}

curl --insecure https://10.0.0.79 -> "ok".
curl -D - --insecure https://129.159.139.0 -> blank 200

But this does not:

129.159.139.0 {
        tls internal
        respond "ok"
}
# curl --insecure https://129.159.139.0
curl: (35) error:0A000438:SSL routines::tlsv1 alert internal error

Windows:

> curl.exe --insecure https://129.159.139.0
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.

Google Chrome: ERR_SSL_PROTOCOL_ERROR

Firefox: SSL_ERROR_INTERNAL_ERROR_ALERT

However, having both sites make them both work:

129.159.139.0 {
        tls internal
        respond "foo"
}

10.0.0.79 {
        tls internal
        respond "bar"
}

curl --insecure https://129.159.139.0 -> "foo"
curl --insecure https://10.0.0.79 -> "bar"

HOWEVER, if I explicitly specify my own cert files, it STILL uses the caddy local cert. With any of the following configs, the Caddy Local Authority cert is always used regardless.

129.159.139.0 {
        tls ssl/129.159.139.0/certificate.crt ssl/129.159.139.0/private.key
        # ...
}

10.0.0.79 {
        tls internal
        respond "test"
}
129.159.139.0 {
        tls ssl/129.159.139.0/certificate.crt ssl/129.159.139.0/private.key
        # ...
}

10.0.0.79 {
        tls ssl/129.159.139.0/certificate.crt ssl/129.159.139.0/private.key
        respond "test"
}
129.159.139.0 10.0.0.79 {
        tls ssl/129.159.139.0/certificate.crt ssl/129.159.139.0/private.key
        # ...
}
10.0.0.79 {
        tls ssl/129.159.139.0/certificate.crt ssl/129.159.139.0/private.key
        # ...
}

2024-05-27_03-23-57-583 129 159 139 0_-_Google_Chrome

So it seems it is not possible to use TLS on a raw NAT'ed IP address, with custom certs (from ZeroSSL for example). It fails to handshake, unless there is another non-NATed IP address anywhere in the caddyfile, but then internal tls is always used regardless.

I also reproduced this issue at my house where my public IP is forwarded to my server. And the VPS that has public IP directly, does not have this issue.

I thought I've done this before, so I tried caddy 2.6.4, 2.5.2, and 2.4.6, but it's the same. I must have used nginx last time.

I did try adding the public IP to the host's interface but it did not change it.

@mholt
Copy link
Member

mholt commented May 29, 2024

What's in the Caddy logs though? (Enable debug mode just in case.) That should reveal the reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants