Turning your Platform Services Controller 6.0 into a Subordinate

To kick things off on this series of articles I plan on publishing, lets get started with promoting my environment's Platform Services Controller (PSC) to a suboridnate of my Microsoft PKI. I'm using a two-tier Microsoft CA server environment. If you are using a different PKI, be it an internal one or an external vendor, some steps may vary.

This is a re-cap of KB2111219 just with some snazzy pictures to assist everyone, so if you've already done this, you can skip this article!

--début--

Head to the Virtual Appliance Management Interface (HTTPS://FQDN:5480), or VAMI for short, of the PSC to toggle on the SSH and BASH access to the system in the event they are not enabled:

Security best practices, what are those?

From there, jump into the PSC with your favorite SSH Client. You'll be greeted with the Appliance Management Shell of which you'll bypass with the following commands (covered in KB2100508):

shell.set --enabled true

shell

Toggle your default shell from Appliance Management over to Bash, this will make life easier when you are downloading and uploading files to the PSC.

chsh -s /bin/bash root

Goodbye, Appliance Management, our time was so short together

For storage purposes, make a directory to store all of your certificates in for later use.

mkdir /ssl

Now that all of that is taken care of, lets open the Certificate Manager Utility (CMU) with the following, and then select Option 2 (Replace the VMCA Root). With the later builds of PSC 6.0U1, VMware now allows for you to customize your solution users (and Machine certificate). For simplicity's sake, I'll skip over the Solution Users for now.

/usr/lib/vmware-vmca/bin/certificate-manager

The CMU, in all of its text-based goodness

Log in with Administrator@vSphere.local and provide the password, and you'll be prompted to setup the configuration file for the Machine SSL certificate. Some notes:

This is the certificate stored in the MACHINE_SSL_CERT VMware Endpoint Certificate Store (VECS) that the reverse proxy uses for securing traffic sent out over Port 443, not to be confused with the VMCA's signing certificate.
If you gave your vDomain a unique name, make sure to use that for the username field.
Take care to make sure that the Hostname or IP address used reflect the PNID that you used when you originally deployed. You can check this by using: /bin/install-parameter system.hostname.type /bin/install-parameter system.hostname
If you made a typo in one of the fields, you can modify the MACHINE_SSL_CERT.cfg located in /var/tmp/vmware using VI and re-run the CSR generating steps above.

From there, select Option 1 and supply the /SSL directory we created at the beginning.

Using an SCP client, log into the PSC, navigate to the /SSL directory and pull down the CSR to your workstation.

Open the CSR in a text editor and copy the entire request.

Open up your favorite browser and log into your PKI's Certificate Request site (for Microsoft CAs, its https://CA_FQDN/certsrv/). Click on Request a Certificate, the Advanced Certificate Request, paste in the CSR into the Saved Request field. From the drop-down, select the Subordinate Certificate Authority certificate template or use the vSphere 6.0 VMCA template generated in KB2112009. Click Submit.

Once the certificate has been generated, ensure you receive the Base 64 encoded version of the certificate chain. If you are using a Microsoft PKI, select the Base 64 encoded radio button then select Download certificate chain. This will provide you with a *.P7B file, containing the root, any intermediates, and your leaf certificate.

Since the PSC does not yet accept P7B certificates, we'll need to extract each of the certificates. Open the certnew.p7b in certmgr and, one-by-one, extract each certificate (root, any intermediates, and the signing certificate) in Base 64 encoded x.509 certificate format. For the continuity of this article, I saved these all into <My User>\Pictures\HomePSC , exporting them according to their order and role in the certificate chain, using the following naming scheme for easy tracking: 1_leaf.cer, 2_intermediate.cer and 3_root.cer.

Now comes the not-so-fun part that I will try an simplify for you: you'll need to manually concatenate the root, any intermediates, and your leaf certificate into one file. You can either:

Open each file in a text editor, copy all of the content from the very beginning of BEGIN CERTIFICATE to the END CERTIFICATE, and paste each one into a single file
Use Command Prompt (or terminal) to concatenate all 3 files into a single file.

For the sake of this article, we'll cover the manual concantenation of the files since its a more visual operation.

Open all three files in a text editor

Create a new text file called root_signging_cert.cer by right-clicking, creating a new text file, naming is accordingly, then changing the extension from *.txt to *.cer. From there, copy the entirity of the certificates one-by-one into the text file in the order below. The image below has most of the text removed from the certificate for easy viewing purposes which is why the file looks so small.

Once this is completed, while not a definitive test, open the final, concatenated certificate to see if it will actually load, and check the certificate chain via the Certificate Path tab.

Simplistically, you want the leaf signing-certificate at the very top of the file, followed by any intermediates, then the final root certificates. In my lab's case, the intermediate is also acting as the issuer of certificates. For individuals who only have just a root certificate authority, that will also act as the issuing authority.

Once all of that is complete, we are ready to pass the final root_signging_cert.cer back to the PSC via SCP. In the end, you should end up with the root_signing_cert.key and *.cer pair stored in the /SSL directory on the PSC.

Head back over to the CMU and pick up where we left off by selecting Option 2 to import the Custom certificates. Supply the file location where we placed the certificate and its key, and then wait for the CMU to install the certificates.

Introduced in 6.0U1b, you'll see the CMU updating all of the VMware Lookup Service endpoints (9 for the PSC), resolving the problem documented in KB2109074, which caused huge troubles for anyone who previously replaced their certificates. For anyone who did run through the afformentioned KB article, I'm sure the thought of re-running ls_update_certs.py made you shutter a bit.

Once all of the services start, don't forget to run the update script for the VAMI so that it picks up the newest Machine SSL certificate generated

/usr/lib/applmgmt/support/scripts/postinstallscripts/lighttpd-vecs-integration.sh

You are now complete. Marvel in all of your glory as you've tackled on PSC's VMCA and left relatively unscathed!

--fin--

Now, you are probably asking yourself: Why, Blair, why did I just submit myself to this? What was the goal? Why, Blair, did you take the time to essentially re-write a KB article just with added flair for the steps and some screenshots? Well, stay tuned.