Why do I get a client SSL/TLS negotiation error when I try to connect to my load balancer?

Short description

A client TLS negotiation error means that a TLS connection initiated by the client was unable to establish a session with the load balancer. TLS negotiation errors occur when clients try to connect to a load balancer using a protocol or cipher that the load balancer's security policy doesn't support. To establish a TLS connection, be sure that your client supports the following:

• One or more matching ciphers
• A protocol specified in the security policy

Resolution

Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.

Identify your load balancer's security policy

From the AWS Management Console:

1.    Open the Amazon Elastic Compute Cloud (Amazon EC2) console.

2.    On the navigation pane, under LOAD BALANCING, choose Load Balancers.

3.    Select the load balancer, and then choose Listeners.

4.    View the security policy.
For Application Load Balancers and Network Load Balancers, find the security policy in the Security policy column.
For Classic Load Balancers, choose Change in the Cipher column to view the security policy.

From the AWS CLI:

• For Application Load Balancers and Network Load Balancers, run the describe-listeners command
• For Classic Load Balancers, run the describe-load-balancers command

Determine that protocols and ciphers that are supported by your load balancer's security policy

Classic Load Balancers support custom security policies. However, Application Load Balancers and Network Load Balancers don't support custom security policies. For more information about security policies, including the default security policy, see the following:

• Application Load Balancer security policies
• Network Load Balancer security policies
• Classic Load Balancer security policies

(Optional) Test your load balancer's security policy

To test the protocols and ciphers that are supported by your load balancer’s security policy, use an open source command line tool such as sslscan.

Using the sslscan command

You can install and run the sslscan command on any Amazon EC2 Linux instance or from your local system. Make sure that the load balancer that you want to test accepts TLS connections from your source IP address. To use sslscan on an Amazon Linux EC2 instance:

1.    Enable the Extra Packages for Enterprise Linux (EPEL) repository.

2.    Run the sudo yum install sslscan command.

3.    Run the following command to scan your load balancer for supported ciphers. Be sure to replace example.com with your domain name.

[ec2-user@ ~]$ sslscan --show-ciphers example.com

Using the openssl command

Or, you can also test your load balancer's security policy by using the openssl command. You can run the openssl command on any Amazon EC2 Linux instance or from your local system.

To list the supported ciphers for a particular SSL/TLS version, use the openssl ciphers command:

*$* openssl ciphers -v

For example, and following command would show ciphers supported by TLS version TLSv1.2:

*$* openssl ciphers -V | grep "TLSv1.2"

Use the s_client command to test TLS versions and cipher suites. To find the strength of particular cipher suites, you can use a website repository such as ciphersuites.info. For example, the following command would show ciphers for www.example.com:

openssl s_client -connect example.com:443

For example, the suite TLS_PSK_WITH_AES_128_CBC_SHA is considered weak. If you use the suite against a server, you receive the following error:

openssl s_client -connect example.com:443 -cipher PSK-AES128-CBC-SHA -quiet 
140062732593056:error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available:s23_clnt.c:508:

The suite ECDHE-RSA-AES128-GCM-SHA256 is considered strong. If you use the suite against the server, you receive a success message similar to the following:

openssl s_client -connect example.com:443 -cipher ECDHE-RSA-AES128-GCM-SHA256 
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 73B49649716645B90D13E29656AEFEBF289A4956301AD9BC65D4832794E282CD
Session-ID-ctx:
Master-Key: C738D1E7160421281C4CAFEA49941895430168A4028B5D5F6CB6739B58A15235F640A5D740D368A4436CCAFD062B3338
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1647375807
Timeout : 300 (sec)
Verify return code: 0 (ok)

You can also use the openssl command to specify the version of the TLS protocol used in the connection. The following example shows a test that verifies that TLS 1.1 is supported by the server:

openssl s_client -connect example.com:443 -tls1_1 -quiet 
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global CA G2
verify return:1
depth=0 CN = *.peg.a2z.com
verify return:1

Update your load balancer's security policy, if necessary

To update your load balancer's security policy to use supported protocols or ciphers and achieve the desired level of security, perform the following actions:

• Update an Application Load Balancer security policy
• Update a Network Load Balancer security policy
• Update a Classic Load Balancer security policy