The resulting files for the SSO service from Part 2 are shown below with a short explanation:
rui.crt – Minted PKCS#7 x.509 certificate from your trusted CA
rui.csr – Base-64 encoded certificate signing request (CSR)
rui.key – Private RSA 2048-bit key
rui.pfx – Password protected PKCS #12 certificate file, private key, and root CA certs
SSO.cfg – OpenSSL certificate request configuration file for the SSO service
Now that you have a installed the SSO service, generated your x.509 SSL certificates, lets proceed to updating the Single Sign On and Lookup Service certificates on your Windows Server 2008 R2 server. My steps are assuming the SSO service is installed in the default directory. If you have changed the path, then you will need to modify the steps.
This process is a bit tedious and error prone, so I would strongly encourage your take a snapshot of your vCenter VM prior to starting these steps so you can easily revert back to a known clean state should you botch the replacement process. For a script which automates this process, you can check out this link. I’ve used that script, and it works great. It just automates the process below, but as you will see, this is tedious so a script is very welcomed indeed.
1. To reconfigure the SSO SSL certificates we first must list the service records for the Group Check, SSO and Security Token Services. Open an elevated command prompt and type the following commands.
SET JAVA_HOME=C:\Program Files\VMware\Infrastructure\jre cd /d C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli ssolscli.cmd listServices https://YourServer:7444/lookupservice/sdk
At this point you should see a lot of output on the screen and three “Service” sections with a bunch of details.
- Use Notepad to create three separate text files, one for each of the services (STS, group check, SSO). I created three text files (sts.properties, gc.properties, admin.properties) in C:\OpenSSL-Win32\Certs. The content of each file is shown below. Of course change your uri hostname to that of your SSO server. In step #6, below, we create a directory where we will copy the new SSO certificates to. This path (ssl=) is required in the properties config file. I would suggest sticking with what I have below, but you can use whatever you want. The “protocol” field is extremely critical and NOT the same for all three services. Using “wsTrust” for all three result in a smoking hole and a dead SSO server. The certificate file used here is the PKCS#7 certificate file (rui.crt) NOT the password protected PFX file.
The “SSL” property is a directory that we will create in a later step to place the SSO SSL certificates. The SSO service needs continuous access, so this directory should not be a temporary location.
friendlyName=STS for Single Sign On
description=The Security Token Service of the Single Sign On server.
friendlyName=The group check interface of the SSO server
description=The group check interface of the SSO server
friendlyName=The administrative interface of the SSO server
description=The administrative interface of the SSO server
3. Create three more text files (sts_id, gc_id, admin_id) in the C:\OpenSSL-Win32\Certs directory. This time we need to put the unique serviceID shown in step 2 (which will NOT be the same for your install, so don’t blindly use my IDs below). Do not enter any additional information to the contents of the file. Do not collect $200, do not pass GO.
- As a check point in our configuration process, you should now have the following files in your Certs directory (minus jks.keystore if you don’t use trusted SQL SSL). I would also strongly suggest taking another snapshot of your SSO VM at this point, in case the certificate replacement process goes south and you need to recover to a known state. Certificate information is also stored in the SSO SQL database, so I would urge that you use SQL Studio to do a SSO database backup as well.
- Stop the vCenter Single Sign On service via the Windows Server Manger.
- This step will import the SSO PKCS#12 certificate into the SSO service certificate store. The SSO service will need continuous access the three certificate files, so place them in a directory that is out of the way and won’t get tampered with by accident. This is the same directory you set in the three configuration files, back in step #2. Using my example, I put all three SSO certificate files into: C:\ProgramData\VMware\SingleSignOn\SSL
Open an elevated command prompt and type the following commands to import the PFX password protected certificate. When prompted for the master password enter the SSO master password you input during the original SSO installation process.
SET JAVA_HOME=C:\Program Files\VMware\Infrastructure\jre cd /d C:\Program Files\VMware\Infrastructure\SSOServer\utils ssocli configure-riat -a configure-ssl --keystore-file C:\ProgramData\VMware\SingleSignOn\SSL\rui.pfx --keystore-password testpassword
- Start the vCenter Single Sign On service via the Server Manager. Note, at this point you could re-run the ssolscli.cmd command in step 1 to list the services again and validate you can still connect. After much troubleshooting, this is a good checkpoint to validate you don’t have a smoking hole. At this point if you browse to the SSO URL (https://SSOServerFQDN:7444/sso-adminserver/sdk) it should now be protected with your trusted SSL certificate.
- To bind the trusted SSL certificate to each of the three services issue the commands below in the same command prompt Window as above. Note that “updateService” is CASE SENSITIVE.
cd /d C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli ssolscli.cmd updateService -d https://SSOServer.Domain:7444/lookupservice/sdk -u [email protected] -p YourPassword-si c:\OpenSSL-Win32\certs\sts_id -ip c:\openssl-Win32\certs\sts.properties
If the command is successful you will see the following:
ssolscli.cmd updateService -d https://SSOServer.Domain:7444/lookupservice/sdk -u [email protected] -p YourPassword -si c:\OpenSSL-Win32\certs\gc_id -ip c:\openssl-Win32\certs\gc.properties
ssolscli.cmd updateService -d https://SSOServer.Domain:7444/lookupservice/sdk -u [email protected] -p YourPassword -si c:\OpenSSL-Win32\certs\admin_id -ip c:\openssl-Win32\certs\admin.properties
- If you are lucky at this point you have successful return codes for all three commands. However, you may not be out of the woods. Next you should reboot the SSO VM and re-run step one to list all three services.
If you get errors such as “Return Code is: OperationFailed”, then Houston, we have a problem. If you see “unable to connect to server” errors while trying to list the services, wait a few minutes and try again. It takes a few minutes for the service to respond to requests.