This post follows on from my previous one on deploying highly available platform services controllers. Normally in my test lab I tend to use self-signed certificates, and just ignore the familiar certificate warnings, but in this case I wanted set up a certificate authority, so I could have a proper look at the new VMCA.
As discussed in the article above, the Platform Services Controller has its own certificate authority – VMCA. You can have VMCA configured in a couple of different ways – the default mode is straight forward in that the VMCA is a self-signed root authority that will issue certificates to other VMware components, such as vCenter and ESXi hosts. In my lab, I am going to configure it in what is known as VMCA Enterprise mode, which is where VMCA acts as a subordinate CA to an existing enterprise root CA (in my case, a Windows based Root CA).
Before I get started, note that all the steps here were done in a test/lab environment. Make sure you do the appropriate testing before implementing! Links to VMware articles can be found at the end of this post.
The first step is to set my platform services controllers up as a subordinate to my root CA, so that it can then issue trusted certificates. To do so, I followed Derek Seaman’s detailed instructions and made use of Derek’s certificate toolkit script, which I recommend highly. The instructions and toolkit walks you through setting up the necessary certificate templates and generating sub-ordinate certificates for the PSCs:
The certificates will be generated in a folder where the script is run from. After following the process there should be a certificate for each PSC node, referencing the node’s FQDN:
Once we have a certificate for each, we can move onto the applying them to the PSCs. Before we can start, we first need to enable the bash shell on the PSC.
Configuring the Platform Service Controllers as a Subordinate CA
To do so, establish an SSH session to the PSC:
The type the following commands to enable the shell:
# shell.set --enabled True # shell
Next, enter the following command to change to the bash shell:
# chsh -s “/bin/bash” root
Now we can upload the certificates we created using WinSCP or PSCP. I created a directory under /root called ‘ssl’, then copied the root_signing_chain.cer and root_signing_cert.key files, generated earlier for that PSC, to it. Note that these are the only files needed, though others will have been created by the script.
With the files on the PSC we can run the certificate manager tool – which is found here: /usr/lib/vmware-vmca/bin/certificate-manager.
We want to replace the VMCA Root certificate with our enterprise subordinate certificate that we uploaded. Select option 2 from the menu, then enter the SSO password. On the subsequent menu, select option 2 and enter the root certificate file names when prompted:
When running through this for the first time you will be prompted for the default values which will populate the certool.cfg file. You should use the same values here that you used when generating the certificate files using the toolkit. When prompted for the hostname, ensure that you enter the FQDN for the PSC that you are currently configuring. Once the process has completed you should have the VMCA on the PSC configured as a subordinate to your enterprise CA. You will be prompted to restart the PSC services:
At this point we can check it’s working as expected by using the FQDN to connect to the PSC using a web browser. If working correctly you should have a secure session without any certificate warnings:
With this in place, we need to repeat all the steps in this section for the other PSC. Once done we should be able to connect to both Platform Services Controllers, using a browser, without receiving any certificate warnings.
Configuring the Platform Services Controllers for High Availability
The first step to configuring the PSCs for high availability is to download the HA scripts from VMware then copy them to the /tmp directory on your first PSC node. The ZIP file from VMware contains the following files:
You can copy the scripts up using WinSCP, as we did before for the certificate files. Once you have the zip file on the PSC node, create a new directory – /ha – then unzip the contents of the zip file to it:
# unzip VMware-psc-ha-6.0.0.2503195.zip -d /ha/
Once done, run the gen-lb-cert.py script – be sure to use the FQDN of the load balancer/VIP:
# python gen-lb-cert.py --primary-node --lb-fqdn=psc.vlab.local
Once complete, Copy /etc/vmware-sso/keys to /ha/keys:
# mkdir /ha/keys # cp /etc/vmware-sso/keys/* /ha/keys
The /ha folder should now look something like this:
Copy the contents of this /ha directory over to a /ha directory created on the other, secondary, platform services controller node. Next, log onto the 2nd PSC node as root and run the gen-lb-cert.py script from the /ha directory:
# python gen-lb-cert.py --secondary-node --lb-fqdn=vra-psc.vlab.local --lb-cert-folder=/ha --sso-serversign
That completes this part of the setup. I’ll be returning to the PSC configuration, in my next post, to complete the setup, but first we need to have a load balancer set up. Look out for my next post on configuring the Citrix Netscaler appliance to provide a load balanced, resilient, connection to the platform services controllers.