Why do SSL/TLS negotiation errors occur when connecting to an Application Load Balancer over HTTPS, and how can I identify the responsible client IP?

Short description

A client TLS negotiation error occurs when a client-initiated TLS connection fails to establish a session with the load balancer.
This error can occur under the following conditions:

• The client uses a cipher or protocol that is not supported by the load balancer’s security policy.
• The client fails to verify the server certificate

When this error occurs, the ClientTLSNegotiationErrorCount metric on the ALB increases.

Summary

1. Check ALB Connection Logs
   • Error codes in tls_verify_status
   • Compare TLS Security Policy and supported Protocols/Ciphers
2. Capture client-side Packet data
3. Compare other logs
   • Compare VPC Flow logs and ALB Access logs
   • Compare ALB Connection logs and ALB Access logs

Resolution

1. Check ALB Connection Logs

1) Error codes in tls_verify_status

If ALB connection logging is enabled and the load balancer fails to establish a connection with the client, the failure reason is recorded in the tls_verify_status field of the logs.
The following error codes indicate possible causes of SSL/TLS negotiation failures:

• ClientCertUntrusted: The client certificate is not trusted.
• ClientCertNotYetValid: The client certificate is not yet valid.
• ClientCertTypeUnsupported: The client certificate type is not supported.

Additionally, certain special values in tls_verify_status require further interpretation:

• -: This value appears if the request does not use an HTTPS listener.
• Failed:UnmappedConnectionError: This occurs when the runtime connection is not mapped properly. This error is logged when a TLS negotiation failure occurs in a non-mTLS (Mutual TLS) scenario.

** Note: Load balancer logs requests on a best-effort basis. We recommend using ALB logs to understand the nature of the requests, not as a complete accounting of all requests.

2) Compare TLS Security Policy and supported Protocols/Ciphers

Each TLS security policy supports a specific set of protocols and ciphers. If the client's request does not conform to these supported configurations, an SSL/TLS negotiation error may occur. By default, ELBSecurityPolicy-TLS13-1-2-2021-06 is assigned to listeners created via the AWS Management Console.
This policy supports the following:

Supported Protocols:

TLS 1.3
TLS 1.2

Supported Ciphers:

TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384

To diagnose the issue, compare the protocol and cipher used by the client with the protocols and ciphers allowed by the ALB listener's security policy. If they do not match, the ClientTLSNegotiationErrorCount metric will increase.

2. Capture client-side Packet data

For precise troubleshooting, capturing client-side packets is the most effective way to determine why TLS negotiation failed and which client IP was affected. Packet capture tools such as tcpdump or Wireshark can help identify the exact cipher and protocol used in the negotiation process. You can also use OpenSSL to manually check which ciphers and protocols are supported by the server:

$ openssl s_client -connect <ALB-Domain>:443 -tls1_2

Replace <ALB-Domain> with your ALB's domain name to test TLS 1.2 support.

3. Compare other logs

1) Compare VPC Flow logs and ALB Access logs

You can enable VPC Flow logs on the ENI(Elastic Network Interface) of your ALB nodes and compare them with ALB Access logs.

• If an SSL/TLS negotiation error occurs, the client's IP may appear in the VPC Flow logs but not in the ALB Access logs.
• This indicates that the ALB received the request but could not complete the connection, possibly due to an SSL/TLS negotiation failure.

2) Compare ALB Connection logs and ALB Access logs

When a client successfully establishes a connection, the conn_trace_id field links the Connection logs with the Access logs.

• If an SSL/TLS negotiation error occurs, compare the conn_trace_id in the ALB Connection logs and ALB Access logs.
• If a connection log exists but no corresponding entry appears in the ALB Access logs, this indicates that the handshake failed before a valid request was processed.

Conclusion & Recommendations

• Verify the client's TLS configuration to ensure compatibility with ALB's security policy.
• Enable ALB Connection logs to capture detailed negotiations failures.
• Use OpenSSL or packet capture tools to diagnose client-side issues.
• Compare VPC Flow logs with ALB Access logs to check whether the client reached ALB but failed to establish a connection.

By following these steps, you can determine the cause of SSL/TLS negotiation errors and identify affected client IPs effectively.

Related Information

[1] CloudWatch metrics for your Application Load Balancer - Application Load Balancer metrics
[2] Connection logs for your Application Load Balancer - Error reason codes
[3] Security policies for your Application Load Balancer
[4] re:Post - How do I identify and resolve client connection issues when I use mTLS with the Application Load Balancer?
[5] re:Post - How do I troubleshoot client SSL/TLS negotiation errors when I connect to an Application Load Balancer that uses HTTPS?
[6] re:Post - Why do I get a client SSL/TLS negotiation error when I try to connect to my load balancer?