LDAP Server Authentication: NSX Uses Certificate Authority (CA)-Based Trust for Simpler Certificate Management

Products

• VMware NSX

Issue/Introduction

Administrators may notice that logins through an LDAP/LDAPS server continue to succeed even after the sub-ca certificate configured for that server has been replaced with a different certificate issued by the same Certificate Authority, or has passed its own expiration date. This is expected behavior and reflects how NSX establishes trust for LDAP connections.

When one or more certificates are configured into an LDAP server's configuration, NSX keeps the last certificate in that list as the trust anchor used for validation.

All trust anchors, across every configured LDAP server and identity source on the Manager, are combined into a single shared trust pool. Once a CA is in that pool, it remains available to validate any LDAP server whose certificate chains back to it  which keeps authentication working automatically through routine certificate renewals, without requiring an update in NSX each time.

At login time, NSX checks the live certificate chain presented by the LDAP server and confirms it leads back to a CA already in the trusted pool.

Example: a server's certificate is reissued under a different intermediate / sub-CA, but that intermediate still chains to the same, already-trusted Root CA. Authentication continues to work with no changes needed in NSX — this is the convenience the design is built around.

Simply disabling a server leaves the anchor in place, which is convenient if you intend to re-enable that server later without re-adding certificates. Removing a server from the configuration is what removes its associated trust anchor.

Editing or removing an LDAP server certificate updates the database (the source of truth), which automatically rebuilds the on-disk LDAP configuration and trust store on every save. Removing an LDAP server entry also removes its trust anchor from the shared pool, so the trust configuration reflects the change.

Only the first entry in the certificates field is used, keeping configuration simple for the common case of one certificate per server.

Environment

All versions of NSX. This is expected behavior across NSX Transformers versions.

Cause

NSX validates LDAPS connections using a Certificate Authority trust model. Rather than validating against one specific certificate per server, NSX validates against a shared pool of trusted CAs. This design is well suited to high-trust environments, such as a single organization running its own internal PKI, where all LDAP servers' certificates are ultimately issued by an already-trusted CA. In these environments, this approach reduces administrative overhead, since routine certificate renewals or intermediate-level changes don't require corresponding updates in NSX.

Resolution

Workaround:

Because trust is CA-based rather than tied to a single certificate, there's no setting to pin NSX to one exact certificate per LDAP server — this is by design and works well when all LDAP servers share a common organizational PKI.

To remove a CA from the trusted pool, delete the LDAP server entry associated with it. Disabling the server instead simply preserves the CA for easy re-enablement later.

No change is required — this reflects the intended design of NSX's CA-based trust model.