Getting an error with LDAP certificate while doing the LDAP integration.
Unable to connect to LDAP server atldaps://xxx.yy.com:636due to error: failed to dial LDAP serverldaps://: LDAP Result Code 200 "Network Error": tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead.xxx.yy.com:636
SSP 5.1.0 or above.
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.
This is expected behaviour and We currently don't have an option to bypass or work around this requirement. Therefore, we require an 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 :
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 :
*.company.com may work depending on hostname usage