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

Open
#4,457 4 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.