SSL_do_handshake() failed (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:SSL alert number 112) while SSL handshaking to upstream, client: 127.0.0.1, server: , request: "GET /lab_control HTTP/1.1", upstream:

[Shivani-shi]

Version

4.0.1

What Kubernetes platforms are you running on?

AKS Azure

Steps to reproduce

In our aks cluster the nginx version was in 2.0.1 and we upgraded it to version 4.0.1. And the upgrade was through helm chart. updating the helm dependency, lease upgrade, and crd upgrades

The upgrade went well but there was a issue for the upstream appliance which was connecting to the application before upgrade with no error but now after the upgrade it has this error
SSL_do_handshake() failed (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:SSL alert number 112) while SSL handshaking to upstream, client: 127.0.0.1, server: , request: "GET /lab_control HTTP/1.1", upstream:

now that we have to fix this error but not at the appliance side but from the cluster side what parameter i should make change to fix this error

nginx-ingress:
enabled: true
controller:
config:
entries:
default-server-return: 302 https://www..........com/
ssl-protocols: TLSv1.2
server-tokens: false
proxy_ssl_server_name: true

Does the addition of proxy_ssl_server_name: true in the values.yaml fix this?

[github-actions]

Hi @Shivani-shi thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!

[pdabelf5]

@Shivani-shi thank you for creating this issue.
Can you let us know if you are using the Ingress or VirtualServer resource for your host?
Also, are you an NGINX open source or NGINX Plus user?
Thanks

[Shivani-shi]

Hi @pdabelf5, good day!
Thanks for your response, we are using the Ingress resource for the host and NGINX open source
will await your response to resolve this issue

[Shivani-shi]

Also want to highlight that the issue of SSL handshake wasnt there before the upgrade to v.4.0.1

[Shivani-shi]

@pdabelf5, another observation we compared Test cluster nginx conf file (upgraded nginx v.4.0.1) with RC cluster (not upgraded) we found that entry ssl_reject_handshake on; which might be causing this issue

Cluster-Side NGINX Config Differences (Test vs RC):

In RC Environment:
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/nginx/secrets/default;
ssl_certificate_key /etc/nginx/secrets/default;

In Test Environment:
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_reject_handshake on;

The presence of ssl_reject_handshake on; In the test environment likely blocks SSL connections that do not match the expected certificate/SNI, resulting in failed handshakes from legacy appliances. so in newer nginx version some field might be different which impacted this.

If you can suggest how to set that SSLRejectHandshake variable to false so that it’s excluded from the file when it’s generated or how to remove this line entirely.

[Shivani-shi]

Is there way to configure to ssl_reject_handshake off?
As I understand, the current logic is, if there are no certs specified by default, then it is set to "on".

We want to set this to off, is there a way for this?
Thanks in advance.

[jjngx]

@Shivani-shi having ssl_reject_handshake off is the change in the default templates. You can use custom templates if you want to modify original templates. Here is an example how to start: link

[Shivani-shi]

@jjngx thanks for the response

However, I also read that modifying this parameter to off does expose the application to security risks. Since I'm not a specialist regarding this topic.

The adjustments that i am noticing (the ones attached above) might also be features/improvements brought from one version to the other. what would be the best approach now or what is missing from our setup to get things going

[jjngx]

@jjngx thanks for the response

However, I also read that modifying this parameter to off does expose the application to security risks. Since I'm not a specialist regarding this topic.

We do not recommend relaxing security settings in the ingress controller. However, the option to use custom templates is a way to test if your applications would continue to work as before upgrading to NIC v4.x.

[jjngx]

@Shivani-shi could you please test the upgrade to NIC v3.0.2 and check if you encounter the same issue? If you don't see the issue with v3.0.2 could you test version v3.1.0?

In NIC v3.1.0 we set ssl_reject_handshake on; by default.

Please see our release notes here on v3.1.0 https://docs.nginx.com/nginx-ingress-controller/releases/#310

[nagashree-nagashree]

@jjngx After upgrading to version 4.0.1, we observed that the TLS secret in our AKS cluster was deleted. As a result, the ssl_reject_handshake on; entry is appearing in the nginx.conf file. Is this a known issue in version 4.0.1, or has this behavior been observed by others as well? Any insights or documentation around this would be helpful.

[nagashree-nagashree]

Hi,

client.go:412: [debug] Created a new Role called "nginx-ingress" in cluster-resources
client.go:412: [debug] Created a new RoleBinding called "nginx-ingress" in cluster-resources
client.go:412: [debug] Created a new Service called "nginx-ingress" in cluster-resources
client.go:412: [debug] Created a new Deployment called "nginx-ingress" in cluster-resources
client.go:443: [debug] Deleting Secret "nginx-ingress-tls" in namespace cluster-resources...
client.go:443: [debug] Deleting Service "nginx-ingress" in namespace cluster-resources...
client.go:443: [debug] Deleting Deployment "nginx-ingress" in namespace cluster-resources...
upgrade.go:427: [debug] waiting for release cluster-resources resources (created: 4 updated: 57 deleted: 3)

The above output from the helm upgrade command indicates that a secret is being deleted.