I want to troubleshoot an SSL/TLS negotiation error I receive 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 didn't establish a session with the load balancer. If a client uses a protocol or cipher that the load balancer's security policy doesn't support to connect, then TLS negotiation errors occur. To establish a TLS connection, make 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 you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshoot AWS CLI errors. Also, make sure that you're using the most recent AWS CLI version.
Identify your load balancer's security policy
Complete the following steps:
- Open the Amazon Elastic Compute Cloud (Amazon EC2) console.
- On the navigation pane, under Load Balancing, choose Load Balancers.
- Select the load balancer, and then choose Listeners.
- 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.
Or, to use the AWS CLI, run one of the following commands:
Determine the 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, see the following documentation:
(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. For more information, see sslscan on the GitHub website.
Use the sslscan command
Install and run the sslscan command on an Amazon Linux EC2 instance or from your local system. Make sure that your load balancer accepts TLS connections from your source IP address.
To use sslscan on an Amazon Linux EC2 instance, complete the following steps:
-
Turn on the Extra Packages for Enterprise Linux (EPEL) repository.
-
Run the following command:
sudo yum install sslscan
-
To scan your load balancer for supported ciphers, run the following command. Replace example.com with your domain name:
[ec2-user@ ~]$ sslscan --show-ciphers example.com
Note: Amazon Linux 2023 (AL2023) doesn't support EPEL.
Use the openssl command
To test your load balancer's security policy, you can also use the openssl command. Run the openssl command on an Amazon Linux EC2 instance or from your local system.
To list the supported ciphers for a specific SSL/TLS version, run the following command:
*$* openssl ciphers -v
The following command shows ciphers supported by TLS version TLSv1.2:
*$* openssl ciphers -V | grep "TLSv1.2"
Run the s_client command to test TLS versions and cipher suites. To find the strength of a specific cipher suite, use a third-party website repository such as Cipher Suite. For example, if you ran the following command, then the output shows ciphers for www.example.com:
openssl s_client -connect example.com:443
The suite TLS_PSK_WITH_AES_128_CBC_SHA is weak. If you use the suite against a server, then 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 strong. If you use the suite against the server, then 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)
To specify the version of the TLS protocol used in the connection, run the openssl command. 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
(Optional) Check connection logs for your Application Load Balancer and access logs for your Network Load Balancer
If your client connects HTTPS listeners for your Application Load Balancer, then use connection logs to check the protocol and the cipher. The protocol and the cipher used for the connection are in the tls_protocol and tls_cipher fields. If TLS negotiation has failed, then the tls_verify_status field is set to Failed:$error_code, and the tls_protocol and tls_cipher fields are set to "-".
If your client connects TLS listeners for your Network Load Balancer, then use access logs to check the protocol and the cipher. The protocol and cipher used for the connection are in the tls_protocol_version and tls_cipher fields. If TLS negotiation has failed, then no access logs are recorded.
For more information, see Connection logs for your Application Load Balancer and Access logs for your Network Load Balancer.
Update your load balancer's security policy
To use supported protocols or ciphers to increase your security, update your load balancer's security policy. For more information about how to update security policies, see the following documentation: