Site Recovery Manager (VLSR) becomes unreachable - Multiple Security Token Service (STS) certificates within the vCenter Single Sign-On (SSO) VMDIR database

Products

• VMware Live Recovery

Issue/Introduction

The Site Recovery Manager (SRM) user interface intermittently becomes unreachable, and the remote plugin displays in a distorted or corrupted state within the vSphere Client. Attempts to access the Site Recovery interface or log in via WebSSO fail with an explicit validation error: "A server error occurred. Signature validation failed. Check the server logs for more details."  

Accessing VLR UI manually displays this error. 

You cannot access the VLR UI from vCenter because the plugin in corrupted. 




vCenter displays an alarm regarding STS Certificates. 




You find numerous TenantCredential Certs in JXplorer. 

Environment

VMware Live Site Recovery 9.x 
Site Recovery Manager (All Versions)

Cause

A significant accumulation of duplicate, stale, or expired Security Token Service (STS) signing certificates within the vCenter Single Sign-On (SSO) VMDIR database leads to this issue. This certificate bloat corrupts the token validation path for external solution extensions. 

This usually happens over years of upgrades, repeated certificate replacements, or expired roots failing to clean up automatically.

Solutions that integrate with vCenter Server via remote plugins (such as VMware Live Recovery / SRM) rely strictly on SAML tokens issued by the Single Sign-On (SSO) service. The dependent solution validates these tokens by matching their cryptographic signatures against the published STS certificate chain stored in VECS and VMDIR. When the database becomes bloated with multiple conflicting TenantCredential entries, token parsing fails, or a key mismatch occurs, triggering an unhandled Signature validation failed exception inside the Envoy proxy or WebSSO engine. This behavior aligns with known vCenter certificate infrastructure limits regarding multi-vCenter Enhanced Linked Mode (ELM) trust propagation.

Resolution

Submit a case with vCenter Management team to delete all the stale STS certificates from the directory service & regenerate a single valid STS signing certificate, and validate the SSO Replication. 

1. vCenter Management will use directory management tools (such as JXplorer or internal CLI utilities) to connect to the VMDIR LDAP node (dc=vsphere,dc=local) and safely remove the extraneous TenantCredential-X and TrustedCertificateChains-X entries.

2. Regenerate a clean, single STS signing certificate using vCert or other tools. 

3. Restart all vCenter management services on all the vCenters in ELM to flush cached certificate states:

   • service-control --stop --all

   • service-control --start --all

4. Log in to the SRM appliance management interfaces on both the production and recovery sides, perform a Reconfigure operation to import the updated vCenter certificate context, and execute a Reconnect on the site pair.