NginxProxyManager / NginxProxyManager/nginx-proxy-manager
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
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 34.2k
- Forks
- 3.9k
- Avg merge
- 21h 12m
- Merged PRs (30d)
- 20
Description
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
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start from the proxy host Advanced tab and the generated upstream TLS configuration. Reproduce a cascade of two NPM instances using the reported SSL_do_handshake error, then verify whether forwarding SNI by default preserves existing proxy behavior and resolves the failure. The exact requested settings are proxy_ssl_name $host and proxy_ssl_server_name on.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nginx
- Domain
- devops, documentation
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 56/100