You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: