LDAP Integration Fails with Error: certificate relies on legacy common name field, use SANs instead

Products

• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

Getting an error with LDAP certificate while doing the LDAP integration.

Unable to connect to LDAP server at ldaps://xxx.yy.com:636 due to error: failed to dial LDAP server ldaps://xxx.yy.com:636: LDAP Result Code 200 "Network Error": tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead.

 

Environment

Fresh install of SSP 5.1.0, SSP 5.1.1
SSP 5.0.0 is deployed and then an LDAP configured using certificate with only Subject Common Name. Now the SSP is upgraded to 5.1.0/5.1.1

Cause

The platform connects Active Directory with LDAPS (ldaps://…) and verifies the TLS certificate using the CA bundle supplied. The certificate the LDAP server presents is trusted (chains to CA), but it does not include a Subject Alternative Name (SAN) that matches the hostname used in the LDAP URL.

The client runtime (Go’s TLS library) no longer treats the legacy Subject Common Name (CN) alone as sufficient for hostname verification, so the handshake fails with: certificate relies on legacy common name field, use SANs instead.

Impact connecting to LDAP:

• New role addition does not work as LDAP is disconnected we dont allow new user addition.
• Remote users which were added previously before upgrade are working and able to login to SSP.

Resolution

This is expected behaviour in SSP 5.1.0. This is not a configurable setting. Customers, are required to use a LDAPS certificate that includes the Subject Alternative Name (SAN) field.

Note : The certificate presented by the LDAP server must contain a Subject Alternative Name (SAN) entry that matches the hostname configured in the LDAPS URL ( These commands non-distributive)

For example, if SSP is configured with:    ldaps://ldap.company.com:636

Then the certificate must include:  DNS:ldap.company.com

Method 1: Validate Using OpenSSL from Any Linux Host:

Run:

openssl s_client -connect ldap.company.com:636 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Subject Alternative Name"

Example output : 
X509v3 Subject Alternative Name:
DNS:ldap.company.com

If no SAN section appears, or the hostname is different, the certificate will fail validation.

Method 2: Full Certificate Review

openssl s_client -connect ldap.company.com:636 -showcerts </dev/null

Copy the server certificate and inspect:

openssl x509 -in ldap-cert.pem -text -noout

Look for:

X509v3 Subject Alternative Name:

Important notes : 

• CN only is no longer sufficient
• SAN must match the hostname used in SSP LDAP integration
• Wildcards like *.company.com may work depending on hostname usage
• IP address in LDAPS URL requires IP SAN, not DNS SAN