In my last few posts, I focused on configuring the vCenter Server Virtual Appliance. Now that the appliance is up and running, it’s time to install and configure SSL certificates from an internal certificate authority. Much like the Windows vCenter application, SSL certificates are very important for vCenter 5.5 appliance.

SSL certificates in vCenter became an issue in vCenter 5.1 when a self-signed or invalid certificate could prevent an upgrade from a previous version from going forward. Those difficulties have been eased somewhat in vCenter 5.5 with the release of a certificate management tool that helps install the required certificates.

Before you can install certificates on the vCenter appliance, there are a few key points you should know about how certificates are used in vCenter and how those certificates need to be created. Derek Seaman covers this very well in his vCenter 5.1 blog. Instead of trying to duplicate his research and work, the links to will be provided below. I HIGHLY recommend that you read his posts on SSL certificates before you attempt to update the SSL certificates on the appliance.

The links to Derek’s blog are:

• vSphere 5.5 Install Pt. 5: SSL Deep Dive
• vSphere 5.5 Install Pt. 6: Certificate Template
• vSphere 5.5 Install Pt. 8: Online SSL Minting

In addition to Derek’s blogs, a few tools you will need to generate and install new SSL certificates. Those tools, which are geared towards a Microsoft environment, are:

• WinSCP – used to copy new certificate files over to the appliance
• Putty – used to access the appliance’s command line remotely to execute commands to install the certificates
• OpenSSL for Windows – Version 0.9.8y is recommended for creating the certificate signing requests for the vCenter Server Appliance certificates
• A PKI environment to mint certificates. This tutorial will use a Windows-based Certificate Authority

The instructions for updating the appliance’s certificates can be found in the VMware Knowledgebase. Those instructions, along with some of the information Derek provided in his blog, will be used for this process.

Getting Started

The first thing that you need to do is create a certificate template on your Windows Certificate Authority. The instructions in Part 6 of Derek Seaman’s blog covers this step very well. The template should be set up as a Windows Server 2003 Enterprise template if it should be available in the Certificate Services Self-Service web portal.

The next step is to download and install OpenSSL for Windows version 0.9.8y on a workstation or server. You should add OpenSSL to the Windows PATH variable. This will make it easier for you to use OpenSSL to generate the certificate signing requests later on.

Each service on the vCenter appliance will need to have it’s own unique certificate. The best way to keep track of the three (or four if Auto Deploy is used) certificate requests is to create folders to organize the certificate signing requests, certificate files, and OpenSSL configuration files. The folders that should be created are:

• VMware vCenter Service Certificate
• VMware Inventory Service Certificate
• VMware Logbrowser Service Certificate
• VMware vCenter Autodeploy Service Certificate (optional, not required if Auto Deploy is not used)

You will need to create an OpenSSL configuration file for each folder. This file will contain the details that OpenSSL needs to create the certificate signing request, and these files will keep OpenSSL from prompting for information when you go to generate the certificate request. You will need to configure the subjectAltName field because your vCenter server will have multiple names that it can be accessed under, including the DNS single label name, fully qualified domain name, and IP addresses. You will also need to fill in your organizational details in the [req_distinguished_name] section.

Most of the fields in the configuration file only need to be changed once. When testing this procedure out, I found that the easiest way to manage this was to create a template with all the fields filled out except for the organizationalunitname field. I would then copy this template into each of the folders that I created, rename it, and then modify the file to update the organizationalunitname.

To create the configuration file, open up a text editor and paste the code below into it:

[ req ]

default_md = sha512
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
input_password = testpassword
output_password = testpassword

[ v3_req ]

basicConstraints = CA:false
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:<DNS short name change me>, IP:<IPv4 Change Me>, IP:<IPv6 Change Me>, DNS:<FQDN Change Me>

[ req_distinguished_name ]

countryName = <Country Change Me>
stateOrProvinceName = <State Change Me>
localityName = <City Change Me>
0.organizationName = <Org Change Me>
organizationalUnitName = <VMware vCenter Service Certificate, VMware Inventory Service Certificate, VMware Logbrowser Service Certificate, VMware vCenter Autodeploy Service Certificate>
commonName = <FQDN Change Me>

As mentioned above, the organizationalunitname field will need to be different for each configuration file. The value in this field should match the name of the service that the certificate will be used with.

There is a sample configuration file below. OpenSSL will generate a certificate signing requests for the vCenter Service Certificate when it is run with this configuration file. The lines that have been bolded are the ones that were updated.

[ req ]

default_md = sha512
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
input_password = testpassword
output_password = testpassword

[ v3_req ]

basicConstraints = CA:false
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:vctest2, IP:10.1.1.161, DNS:vctest2.homedomain.private

[ req_distinguished_name ]

countryName = US
stateOrProvinceName = Wisconsin
localityName = Kimberly
0.organizationName = homedomain
organizationalUnitName = VMware vCenter Service Certificate
commonName = vctest2.homedomain.private

Note: Make sure to use your ISO two letter country code otherwise you will get an error when trying to generate the certificate request. 

Creating the Certificate Signing Requests

The certificate signing requests are files that the certificate authority will use to mint new SSL certificates. OpenSSL will be used to generate these, along with a new private key, after the configuration files are made. Three (or four if AutoDeploy is used) of these files will need to be created.

In order to create them, open a command prompt as an adminstrator and navigate to the folder where your OpenSSL configuration files are stored. You will need to run the following command to generate the certificate requests:

openssl req -new -nodes -out rui_service.csr -keyout rui_service.key -config openssl_service.cfg

If you wanted to generate the certificate request for the vCenter Server certificate, you’ll want to open a command prompt as administrator, navigate to where your openssl_vpxd.cfg file is stored, and run OpenSSL this way:

openssl req -new -nodes -out rui_vpxd.csr -keyout rui_service.key -config openssl_vpxd.cfg

Submitting the Requests to the Certificate Authority

I’m not going to do a step-by-step walkthrough of submitting the requests to your certificate authority.

Once you have created all of the certificate requests, you need to submit them to your certificate authority to generate the certificates. If you are in a windows environment, there are a couple of ways to do this. You can submit them through the self-service web portal that can be accessed by going to http://nameofcertserver/certserv. You can also use the certreq.exe command line tool to submit the request.

If you created the VMware-SSL certificate template per Derek Seaman’s post, then you’ll want to use that template for generating the certificates. Otherwise you could use the Web Server template.

After you have created each certificate, you will need to download the certificate file as a Base64-encoded certificate file and save it as a .crt file. Windows Certificate authorities usually save the files as a .cer. You will also need a Base64-encoded copy of the certificate authority chain. This will include the root certificate and any intermediate certificates that might be used in your environment. This file comes as a .p7b, but I’ll cover converting that to a .pem file in the next post.

Speaking of next posts, I will be covering what to do now that the certificates have been created.