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?
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
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
- AWS OFFICIALAktualisiert vor einem Jahr
- Wie verwende ich TLS-Zertifikate, um HTTPS-Verbindungen für meine Amazon-EKS-Anwendungen zu aktivieren?AWS OFFICIALAktualisiert vor einem Monat