With the installation of vCenter 5.1 components (just like vSphere hosts) the components are installed with self signed certificates. No problem when you trust your own systems, but securing your environment when you have different interactions with the services (for example the corporate users of the vSphere web clients) will lead you to implement signed certificates. Especially when the most environments have their own CA infrastructure, use it!

There are seven separate components in vCenter Server 5.1 that utilize certificates to encrypt communication. We want don’t want to spend time generating and installing certificates for each component, we want automation! And what do we have that, the VMware SSL Certificate Automation Tool. Well…..not a complete automation, but automated enough to help updating the vCenter related services (and rollbacking in case something is going wrong). That beats doing it all on yourself.

The VMware SSL Certificate Automation Tool can be used to generate certificate signing requests for the vCenter services, that can be send to the CA to be signed. The Automation Tool can then be used to implement the certificates for the services. Use the planner option to be presented with the correct order of steps. Possibly in a second screen.


The procedure is as follow:

– Download the VMware SSL Certificate Automation Tool.
– Generate CSR’s for the vCenter Service with the automation tool.
– Sign the CSR’s in the CA.
– Creating the PEM chain files.
– Update the vCenter services in the correct order. (Replacing one service and not re-trusting the interacting services will have some errors as result)


The installation starts with downloading the Automation Tool at https://my.vmware.com/group/vmware/get-download?downloadGroup=SSL-TOOL-101. Download and unzip to a preferred location. For this example I have unzipped to D:Scripts, a the folder structure starts from SSLAutomationTool1.0.1.

Predefining the default values in the tool helps prevent typing errors and save time, you can edit ssl-environment.bat. This lets the tool automatically include specific information that you have defined as the default instead of prompting you for it. Details for the serveral services we will fill in after generating the CSR (plus key’s) and PEM chain files.

For now we add the parameters to: Common parameters (SSO and VC users) and parameters that will be used to generate a CSR (fqdn, ips, country, state, organization and so on).

Now we start the tool: ssl-updater.bat.


We first generate the CSR by choosing action 2. At that menu we choose every service we have to update. With the common parameters we only have to take the default entries (be sure to check them). The CSR’s are saved to the requests directory. There you will also find the keys. Repeat until you have selected all options.

With all the necessary services done, we have a collection of CSR’s to be signed by the CA. The process of signing differs from what product is used as CA. From every directory the rui.csr is the signing request we have to upload or open and copy the contents.

For example Microsoft CA works with a web site you can use to request the certificate:


Choose the request a certificate and an advanced request. Request an BASE64-encoded web server certificate, with the option Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

You will have to repeat the request for every service you wish to update.

We continue when we have received the signed requests. Save the .crt file in a appropriate location and open the file to verify the proper names.

After repeating this we have to create PEM files with the complete certificate chain in one file. Depending on the hierarchy used in the certificate infrastructure you will need the root and all the intermediate (if any) Base64-encoded certificates. Get them from your trusted certificate store or from the CA signing service. Also save these files to the directory. Open a text editor and create a PEM file (name including the service). Open the signed certificate and copy and paste to the PEM, open any intermediate certifcate and past the contents to the PEM (after the —-END Certificate — of the certificate), repeat for any other intermediate. Finish by copying the root certificate in the PEM. This should look like something like this (truncated):

——-BEGIN CERTIFICATE——- <——-Certificate
——-BEGIN CERTIFICATE——- <——-Intermediate Certificate
——-BEGIN CERTIFICATE——- <——-Root Certificate

Close and repeat. And we now have the PEM chain’s for all (or you choice) of vCenter services.

Now we need to implement them at the appropriate services. First edit the ssl-environment.bat for the services and include location for keys and pem files. When you are finished the menu options Update will handle the updates for you.

Here is a screenshot of the the updating of the SSO service. It handles the update and restarting of the appropriate services.


Type 3 to return to the main menu and repeat for the other actions the planner .

In case something goes amiss rollback and you can find the service-update-ssl.log in the logs directory of the automation tool.

One more thing, when updating the vCenter certificate one of the wanted information is “Enter vCenter server original database password”. This is a somewhat confusing line. But it is the vCenter database user password (ODBC System DSN Password for connection to VCDB) that is requested. That is either a Windows user or a SQL user.

—- Enjoy updating!

Share this: