Resolving LDAP SSL Handshake Failures After TAS 10.x Upgrade
Article ID: 435727
Updated On:
Products
Issue/Introduction
Following a platform upgrade from Version 6.x to 10.x, users reported an inability to log in via the Cloud Foundry Command Line Interface (cf CLI) or the Apps Manager UI.
When attempting to authenticate, the system returns a javax.naming.CommunicationException. A deep dive into the logs reveals the following underlying error:
javax.net.ssl.SSLHandshakeException: (handshake_failure) Received fatal alert: handshake_failure
While external connectivity tests (such as openssl s_client) to the LDAP server appear successful, the internal UAA (User Account and Authentication) component is unable to establish a secure socket with the LDAP endpoint (ldaps.example.com:3269).
Cause
Troubleshooting: Identifying the LDAP Cipher Suite
To confirm if the LDAP server is the source of the mismatch, you must identify which cipher suites it supports. Use the following commands from a jumpbox or a VM with network access to the LDAP server.
Method A: Using OpenSSL (Quick Check)
This command attempts to connect to the LDAP server and prints the negotiated cipher.
openssl s_client -connect ladps.example.com:3269 -tls1_2
What to look for: Look for the line starting with Cipher :.
If it shows
AES128-SHA(orECDHE-RSA-AES128-SHA), you have confirmed the use of a legacy CBC/SHA-1 cipher.
The root cause is a Security Baseline Mismatch between the upgraded platform and the legacy LDAP server configuration.
The Java 17 Hardening
TAS 10.x utilizes a Java 17 runtime. Unlike earlier versions, Java 17 enforces a strict security policy defined in the java.security configuration file. Specifically, it deprecates and disables algorithms deemed "weak" by modern standards, including:
SHA-1 Hashing: No longer considered collision-resistant.
CBC (Cipher Block Chaining) Mode: Vulnerable to padding oracle attacks (e.g., Lucky13).
The Cipher Conflict
The LDAP server in this environment is configured to use AES128-SHA (TLS_RSA_WITH_AES_128_CBC_SHA). Diagnostic logs from the UAA JVM explicitly show the system rejecting this cipher:
DEBUG | Ignore disabled cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA
Because the UAA (Client) is prohibited from "offering" this legacy cipher and the LDAP server (Server) only accepts this cipher, the TLS handshake fails instantly as there is no mutually supported encryption method.
Resolution
To restore authentication services and align with modern security best practices, the LDAP infrastructure must be updated to support Authenticated Encryption (AEAD).
Recommended Action
The LDAP administrators should enable modern GCM-based (Galois/Counter Mode) cipher suites on the LDAP server or its preceding Load Balancer.
The TLS cipher suites VMware recommends using within Tanzu Operations Manager are:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Feedback
