sslEnabled parameter is set to 'true' but IDSP connects using LDAP insteads of LDAPS

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

We recently enabled SSL for the IDSP connection to the LDAP store in the LDAP configuration. However, based on the logs, SSL is not being used.

We enabled logLevel = debug in Global Settings using Postman and reviewed the auth-mgr pod logs.

The logs show the connection URL as ldap://xx.xx.xx.xx:636, whereas it is expected to be ldaps://xx.xx.xx.xx:636. In addition, the logs indicate SSL: false.

$ kubectl logs -l app.kubernetes.io/name=ssp-auth-mgr -f  | grep -i "xx.xx.xx.xx" | grep -i ssl
{"timestamp":"2026-01-14T06:04:54.326160Z","type":"log","level":"debug","thread":"qtp751316099-29","msg":"Getting server connection for LDAP Config: xxxxxxxx (Type: ldap, ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, URL: ldap://xx.xx.xx.xx:636, statusEncoding: siteminder, isAuthoritativeForIDLCM: false, isAuthoritativeForUserCredsLCM: false, isAuthoritativeForDetectingLockedState: false), BindDN: cn=xxxx,ou=xxxx,dc=xxx,dc=xxx,dc=xxx,dc=ss, connectTimeout 30000ms, readTimeout 60000ms, SSL: false, ignoreSSLValidation: false, ...

Environment

IDSP 3.4.2

Cause

There is a trailing space in the value "true" for the sslEnabled parameter.

Resolution

Remove the unnecessary trailing space from the value "true" of the sslEnabled parameter.

When the sslEnabled parameter in the LDAP configuration is set to the value "true " (that is, with a trailing space), IDSP connects to the LDAP directory without SSL.

For an SSL connection to be enabled, the sslEnabled parameter must be set exactly to "true", with no trailing spaces.

We can confirm that when the parameter is set to "true" (without any trailing space), IDSP connects using LDAPS. If the parameter value is not exactly "true", IDSP interprets it as "false", and regardless of the certificate configuration, IDSP connects using LDAP.

Although sslEnabled is a Boolean parameter, it accepts a string value to maintain backward compatibility across different IDSP versions. To address this issue, parameter values will be trimmed in IDSP 4.0.2 and later.

However, with regard to input validation, enforcing strict acceptance of only true/false values is not possible due to backward compatibility requirements.