Issue with an external VMware PSC High Availability deployment

Starting with vSphere 6, components for license, certificate management and SSO are being handled by the PSC (Platform Services Controller). This new part of a vSphere installation can be configured to be highly available.

I came across an issue where a fresh installation of vCenter Server 6.0 using an external high availability deployment of PSC would fail with a certificate or invalid credentials error. This article describes the issue and how it was solved.

Following this guide (Configuring PSC 6.0 High Availability for vSphere 6.0 using vCenter Server 6.0 Appliance) you’re able to deploy PSC in a high available setup, providing a higher availability and better scaling when your environment requires it.

See the image below as reference.

VMware Platform Services Controller in HA

To do this, you require a load balancer which provides SSL offloading and use of Virtual Servers or a pool of servers which can be access by a single IP address or VIP (Virtual Private IP address). Next you need an SSL certificate and configure your PSC nodes using the additional HA scripts and configurations which are also described in the article mentioned above.

After deploying the PSC nodes as described in the article using a F5 load balancer in front, the deployment of a fresh vCenter Server 6.0 appliance didn’t go as planned. During the  installation wizard, a valid connection to the PSC VIP could not be made. Errors like “Incorrect credentials” and “hostname in certificate didn’t match” were appearing, even when the certificates were correct.

There are actually other articles writing about the same issue and error messages, where sometimes it had to do with the local certificate store (when not using the appliances) or DNS issues. This wasn’t the case in my situation.

Connecting directly to one of the PSC nodes allowed the installation to continue, but obviously this is not what we wanted.

After repeating the whole deployment process with fresh PSC’s and newly created entities inside the F5 the same issue existed.

Eventually, after looking at the F5 configuration it appears that it was actually using the wrong ports in the pools. This was the risk of using the “Repeat” function inside the F5, leaving wrong details in there, while they need changing. Correcting this configuration fixed the described issue! The specific steps for configuring your F5 for use with PSC HA can be found here. A typical RTFM situation to be honest!

To do a quick check of your configuration, use the Network Map function as shown below.

Just for reference, the following error messages could appear when something is wrong with your F5 configuration:

• Ensure that proper addresses of vCenter Signle Sign-On were used during installation
• The SSL certificate does not match when connecting to the vCenter Single Sign-On: hostname in certificate didn’t match
• Unable to add a solution user and administrator user of vCenter Single Sign-On to the Component Manager Administrators group
• install.cm.error.ssl_mismatch
• Progress Controller: [VCSA ERROR] – First Boot error

If this doesn’t solve your issue, please see these additional resources:

• Blog article about invalid credentials by Duco Jaspars
• Derek Seaman’s guide for generating and installing PSC Machine certificates

And if you’re starting to pull your hair (well actually before you are), please contact VMware Support to submit a Support Request and they will help you solve the issue.