Home > Software design >  NGINX - Remove TLS v1.3
NGINX - Remove TLS v1.3

Time:06-27

We are facing 502 error at our IIS web server, which used to work fine up to recently.

We had to change our reverse proxy machine: went from Ubuntu 18.04 to Ubuntu 22.04, and in this proccess the NGINX version changed from 1.21.3 to 1.18.0.

Right now, with NGINX 1.18.0, the 502 occurs. At NGINX log we see:

peer closed connection in SSL handshake (104: Unknown error) while SSL handshaking to upstream

The connection is being served with TLS v1.3, as informed by Mozilla Firefox 101.0.1 (64-bits).

We're working with a Windows Server 2012, which only accepts TLS up to v1.2 (https://docs.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-).

At upstream log there is nothing. If we go back to older NGINX the connection goes without problem (TLS is v1.2). So the problem seems to be at NGINX. We suspect it to be from TLS v1.3 (as per link provided), but couldn't manage to solve this.

We tried updating "nginx.conf" ssl_protocols TLSv1 TLSv1.1; but it didn't work, we still get TLS v1.3. We also tried to update NGINX (apt update and no version change) and some settings (proxy_ssl_name and proxy_ssl_server_name and proxy_pass) with no success either.

Any ideas on how to solve this?

CodePudding user response:

Any ideas on how to solve this?

We're working with a Windows Server 2012, which only accepts TLS up to v1.2

Yup, you identified the problem right there. Win8 won't support TLS1.3. Yet you have a business need to communicate over TLS1.3. Sounds like you want to swap some portion of your deployed software stack.

You could revert to your old Bionic Beaver, but you're likely better off sticking with Jammy. Time has moved on. You want your stack components to keep up with a changing Internet.

CodePudding user response:

We understood that the reason for the 502 error was NGINX didn't accept a private certificate while proxying the connection (our IIS had a private certificate - locally generated).

This case was closed by removing SSL from internal segment (between nginx and IIS), while keeping SSL v1.3 from the user/client to NGINX segment.

  • Related