Why do I get a client SSL/TLS negotiation error when I try to connect to my load balancer?
I receive a Secure Sockets Layer (SSL)/Transport Layer Security (TLS) negotiation error when I try to connect to my load balancer. Why am I getting this error?
"I receive a Secure Sockets Layer (SSL)/Transport Layer Security (TLS) negotiation error when I try to connect to my load balancer. Why am I getting this error?Short descriptionA 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 ciphersA protocol specified in the security policyResolutionNote: 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 policyFrom 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 commandFor Classic Load Balancers, run the describe-load-balancers commandDetermine that protocols and ciphers that are supported by your load balancer's security policyClassic 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 policiesNetwork Load Balancer security policiesClassic Load Balancer security policies(Optional) Test your load balancer's security policyTo 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 commandYou 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.comUsing the openssl commandOr, 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 -vFor 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:443For 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-SHA256Server public key is 2048 bitSecure Renegotiation IS supportedCompression: NONEExpansion: NONENo ALPN negotiatedSSL-Session:Protocol : TLSv1.2Cipher : ECDHE-RSA-AES128-GCM-SHA256Session-ID: 73B49649716645B90D13E29656AEFEBF289A4956301AD9BC65D4832794E282CDSession-ID-ctx:Master-Key: C738D1E7160421281C4CAFEA49941895430168A4028B5D5F6CB6739B58A15235F640A5D740D368A4436CCAFD062B3338Key-Arg : NoneKrb5 Principal: NonePSK identity: NonePSK identity hint: NoneStart Time: 1647375807Timeout : 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 G2verify return:1depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global CA G2verify return:1depth=0 CN = *.peg.a2z.comverify return:1Update your load balancer's security policy, if necessaryTo 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 policyUpdate a Network Load Balancer security policyUpdate a Classic Load Balancer security policyFollow"