vCenter Server Entra ID Domain User Login Failure After Enabling SSL Inspection

Products

• VMware vCenter Server

Issue/Introduction

Organizations using Microsoft Entra ID–integrated authentication may encounter login failures for Entra ID domain users on vCenter Server. This issue typically surfaces after changes are made to network security infrastructure, such as enabling SSL inspection on a proxy server.

Review /var/log/vmware/vc-ws1a-broker/federation-service.log on the vCenter Server, which shows TLS handshake failures when attempting to connect to login.microsoftonline.com:

YYYY-MM-DDTHH:MM:SS INFO  <vc_fqdn>:federation (vert.x-eventloop-thread-27) [-;-;-;-;-;-] org.bouncycastle.jsse.provider.ProvTlsClient - [client #12515 @75de2833] opening connection to login.microsoftonline.com:443
YYYY-MM-DDTHH:MM:SS INFO  <vc_fqdn>:federation (vert.x-eventloop-thread-27) [-;-;-;-;-;-] org.bouncycastle.jsse.provider.ProvTlsClient - [client #12515 @75de2833] raised fatal(2) certificate_unknown(46) alert: Failed to process record org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
.
.
Caused by: java.security.cert.CertificateException: Unable to construct a valid chain
.
.
Caused by: java.security.cert.CertPathBuilderException: No issuer certificate for certificate in certification path found.

These errors indicate that the certificate presented during the TLS handshake could not be validated.

Environment

vCenter Server 8.x

Cause

vCenter Server includes a service known as VIDB (vc-ws1a-broker), which is responsible for communication with Microsoft Entra ID.

When SSL inspection is enabled on the proxy, the proxy presents a certificate signed by its own internal CA. Since VIDB service does not automatically trust this CA, certificate chain validation fails, resulting in Entra ID authentication errors.

Resolution

Prerequisite: VMware vCenter in Enhanced Linked Mode pre-changes snapshot (online or offline) best practice

To resolve the issue, add the proxy server’s CA certificate(s) to the keystore used by the vCenter VIDB (vc-ws1a-broker) service.

Step 1: Identify the VIDB Keystore Location

VIDB service runs inside a container and uses its own JRE keystore. As a result, it does not rely on VECS or the system-wide trust store.

Note:

• <HASH> directory name is unique to each deployment.

• JRE version (for example, jre-17.0.10) may vary depending on the vCenter Server version.

Typical keystore location:

/storage/containers/vc-ws1a-broker/<HASH>/rootfs/usr/local/jre-17.0.10/lib/security/cacerts

Step 2: Create a Complete Certificate Chain

If the proxy uses an intermediate CA, ensure the full certificate chain is imported. Concatenate the certificates in the correct order:

cat domain.der intermediate.der root.der >> chain.crt

 

Step 3: Import the Proxy CA Certificate(s)

keytool -noprompt -storepass changeit -import -trustcacerts -file "<location to cert file on disk>"  -alias <some alias> -keystore "path to the store from Step 1"

 

Step 4: Restart the VIDB Service

service-control --restart vc-ws1a-broker