Recently we added some extra values to the Certificate Subject Alternative Name (SAN) for diversification in accessibility to the vCSA. However, when trying to reach the vCSA by the new SAN value we received the following error message:
“[400] An error occurred while sending an authentication request to the vCenter Single Sign-On server – An error occurred when processing metadata during vCenter Single Sign-On setup: the service provider validation failed. Verify that the server URL is correct and is in FQDN format, or that the hostname is a trusted service provider alias.”
To “solve” this issue, apply the following workaround provided by VMware.
First step is to log into your vCSA through ssh and stop the vSphere ui
root@vcsa [ /etc/vmware/vsphere-ui ]# service-control --stop vsphere-ui
Operation not cancellable. Please wait for it to finish...
Performing stop operation on service vsphere-ui...
root@vcsa [ ~ ]# cd /etc/vmware/vsphere-ui/
Find the webclient.properties file
root@vcsa [ /etc/vmware/vsphere-ui ]# ls -l
total 44
-rw-r----- 1 vsphere-ui root 4856 Oct 8 17:20 webclient.properties
Edit the webclient.properties file
root@vcsa [ /etc/vmware/vsphere-ui ]# vi webclient.properties
Remove the comment (#) in front of the line “sso.serviceprovider.alias.whitelist=” and add the desired SAN values. Use comma seperated if you want to add multiple names. For instance:
sso.serviceprovider.alias.whitelist=vcenter01, vcenter1
Once you’re done with editing, hit escape followed by :wq! to save the file
Last step is to start the vSphere ui
root@vcsa [ /etc/vmware/vsphere-ui ]# service-control --start vsphere-ui
Operation not cancellable. Please wait for it to finish...
Performing start operation on service vsphere-ui...
Successfully started service vsphere-ui
When you try to login after the above adjustments, it could take a while for the login process to finish. If you still run into problems logging in, it could help to clear your browsing data (history, cookies, cache etc).