Active Directory Users Cannot Log In to vCenter After Machine SSL Certificate Replacement
search cancel

Active Directory Users Cannot Log In to vCenter After Machine SSL Certificate Replacement

book

Article ID: 448143

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

After replacing the Machine SSL certificate on VMware vCenter Server, Active Directory (AD) users are unable to authenticate using the secure LDAP (LDAPS) identity source.

The websso.log file dynamically captures the following errors during the failed authentication handshake:

ERROR websso[...] [CorId=...] [com.vmware.identity.interop.ldap.OpenLdapClientLibrary] Server SSL certificate not trusted: Subject () 
WARN websso[...] [CorId=...] [com.vmware.identity.interop.ldap.LdapErrorChecker] Error received by LDAP client: com.vmware.identity.interop.ldap.OpenLdapClientLibrary, error code: -1 
ERROR websso[...] [CorId=...] [com.vmware.identity.idm.server.ServerUtils] cannot establish ldap connection with URI: [ldaps://<REDACTED_HOSTNAME>:<REDACTED_PORT>] because [com.vmware.identity.interop.ldap.ServerDownLdapException] with reason [Can't contact LDAP server]
ERROR websso[...] [CorId=...] [com.vmware.identity.interop.ldap.SslX509EqualityMatchVerificationCallback] Server SSL certificate verification failed for [Subject: ] [SHA1 Fingerprint: <REDACTED_SECRET>].: \nServer SSL certificate not a trusted certificate nor signed by a trusted certificate

Environment

 

  • VMware vCenter Server 8.0U3

  • Active Directory configured with an LDAPS Identity Source

 

Cause

The LDAPS Identity Source configuration within the vCenter Single Sign-On (vmdir) database was pinned to a specific Domain Controller leaf/server certificate rather than the overarching Root and Intermediate Certificate Authority (CA) chain.

While the system was operational, the websso service utilized long-running, cached secure LDAP sessions. Replacing the vCenter Machine SSL certificate forced a restart of the Single Sign-On stack, dropping these cached sessions. Upon service initialization, a fresh TLS handshake was negotiated against the Domain Controller. Because the identity source configuration lacked the complete trusted CA hierarchy or pointed to a modified leaf, the internal validation layer (SslX509EqualityMatchVerificationCallback) rejected the handshake to preserve the security boundary.

Resolution

 

  1. Log in to the vSphere Client using administrative credentials (such as [email protected]).

  2. Navigate to Administration > Single Sign-On > Configuration.

  3. Select the Identity Sources tab.

  4. Highlight the affected Active Directory over LDAPS identity source and click Edit.

  5. Under the certificates section, upload the complete, valid Root CA and Intermediate CA certificates belonging to your Active Directory Certificate Services (AD CS) infrastructure.

  6. Click Save.

  7. If the configuration database contains strict formatting constraints that prevent editing, select the identity source, click Delete, and then click Add to recreate the LDAPS connection using the correct CA trust chain.

 

Additional Information

 

  • Content focused strictly on this specific break/fix scenario.

  • For further details regarding secure identity mapping configurations, please consult the canonical Broadcom TechDocs Portal.

 

Powered by Wolken Software