Skip to content

Solution: SSL_do_handshake() failed (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:SSL alert number 112) while SSL handshaking to upstream #4457

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

Open
JoachimSchurig opened this issue Mar 27, 2025 · 0 comments
Labels

Comments

@JoachimSchurig
Copy link

Thank you for providing the NGINX proxy manager!

I write this for people searching a solution for the above problem, I am unsure if the author is watching this.

When you try to cascade two NPM instances, the later instance will always refuse any TLS connections from the former with the above error.

Because the debug output of NPM is so limited it took me really some hours to understand the reason. I hope to spare these to some.

The point is that, when using TLS, all of the inner workings of NPM rely on server name identification inside TLS (or: SNI)

This is a mechanism where browsers send the host name of the target unencrypted when starting the TLS negotiations - NPM would not function without this, as this is where it can see which target host is requested and which TLS certificate it shall present. Do not mix this up with the Host header (which will contain the same information, but it will be sent only AFTER the above TLS negotiation took place).

The point is that when you redirect a hostname to another TLS host, NPM per default does NOT send the SNI host name onwards.

And when that target host is just another NPM instance, such as I do to provide access to my IPv6 only infrastructure from an IPv4 proxy (but any other config will do), this target does not receive the originally requested host name and responds with the above error message as it does not know with which certificate to respond.

The remedy is easy:

Open the Advanced tab of your proxy host configuration, and enter these lines:

proxy_ssl_name $host;
proxy_ssl_server_name on;

that's it!

And, to the author, please add this to your default config. Your software is addressed to non-pros. It should work out of the box in this configuration as well. Or add a config checkbox if you fear the clear name transmit of the target server to make it an option.

Again, thanks for adding the nice interface to nginx.

If I may ask one other question: why using openresty? That makes me feel a bit uneasy because I do not know the team that supervises it. NGINX is well known though.

Thanks again,
Joachim

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

No branches or pull requests

1 participant