WoodITWork.com

This is part 3 of a 4 part post on managing vSphere 5 Certificates:

1. Installing a Root Certificate Authority
2. Distributing the root CA certificate to clients
3. Replacing the default vCenter 5 Server Certificate
4. Replacing the default Update Manager 5 Server Certificate

You should now have a root CA certificate distributed to all clients so you can proceed with creating certificates for vCenter 5 which will be trusted by this root CA certificate. These steps will also allow you to create DNS aliases for your certificate if you need them so you can connect to your vCenter server using any of the aliases and still have a valid certificate.

In order to create certificates you will need an application to generate them, one of the easiest is OpenSSL.

Installing OpenSSL
If you install OpenSSL on a vCenter Server, as vCenter 5 only installs on 64-bit you should download the 64-bit version of Win64 OpenSSL v1.0.0e Light and its pre-requisite
Visual C++ 2008 Redistributables (x64)

Install Visual C++ 2008 using all default settings.

Install Win64 OpenSSL v1.0.0e Light

I installed to the default directory C:\OpenSSL-Win64\

Select to Copy OpenSSL DLLs to The OpenSSL binaries (/bin) directory

If you are of generous disposition you can always make a donation.

You are now ready to create the vCenter certificates.

The certificate creation process will ultimately create 3 files:

1. X.509 certificate file with RSA public key in PEM format, named rui.crt
2. RSA private key in PEM format, named rui.key
3. PKCS12 bundle of the same certificate and key, named rui.pfx

Certificate DNS Aliases

One thing to bear in mind is that by default certificates are tied to the exact server name they are created for which is normally the FQDN of the server. If you create a certificate for the server lonvc01.lab.int and then connect by the short name lonvc01 or by any other DNS alias such as myvc for example the certificate will not be seen as a trusted certificate even though a connection to vCenter will be possible.

You can actually amend the default certificate creation process to specify particular aliases within the certificate so you can connect with both lonvc01.lab.int and also lonvc01.

Navigate to the folder where you installed OpenSSL, for example, C:\OpenSSL-Win64\

Make a backup copy of the default OpenSSL configuration file, openssl.cfg and then open it in a text editor.

Find the [ req ] section and add the following line:

req_extensions = v3_req

Find the [ v3_req ] section and add a new subjectAltName line listing the required DNS names including the full FQDN for example:

subjectAltName = "DNS:lonvc01.lab.int, DNS:lonvc01"

Save the openssl.cfg file.

You should remember to replace the openssl.cfg file with the original when you are finished creating the certificates as the same DNS alias will be applied to future certificates generated.

Creating the Certificate Files

You can now use OpenSSL to create a certificate using this modified configuration file.

Launch a command prompt and change directory to the OpenSSL /bin directory.

cd C:\OpenSSL-Win64\bin

You need to set an environment variable pointing to the OpenSSL configuration file otherwise it can’t find it so in this example type:

C:\OpenSSL-Win64\bin\openssl.cfg

Create a new key for the vCenter Server with the following command:

openssl req -new -nodes -out rui.csr -keyout rui.key

You will then need to add the certificate information into the certificate request. What you enter may depend on the standards you have in your company and some fields are optional.

Common Name is the most important field as you need to enter the FQDN server name of your vCenter Server to generate a certificate based on that name.

My certificate is generated with the following information:

Country Name (2 letter code) [AU]:UK
State or Province Name (full name) [Some-State]: <Blank>
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:lab.int
Organizational Unit Name (eg, section) []: <Blank>
Common Name (eg, YOUR name) []:lonvc01.lab.int
Email Address []:vcadmin@lonvc01.lab.int
A challenge password []:password
An optional company name []:<Blank>

You will see two new files have been created rui.csr and rui.key which represent the certificate created.

Certifying the certificate with the Root CA

The file holding the key rui.csr needs to be uploaded to the Root CA Certificate Authority and needs to be then trusted.

Launch Server Manager and navigate to Roles | Active Directory Certificate Services and then your root CA authority name, in my example, Self-Signed CA for lab.int.

Right click and select All Tasks | Submit New Request

Browse to the rui.csr file you previously created and click Open

Navigate to the Pending Requests folder and you will see the certificate has been imported, you can check you have the right certificate by right-clicking and selecting View Attributes/Extensions and checking the certificate name. When you are sure you have the right certificate, right click and select Issue which will sign the certificate with the root CA certificate information.

You can check the certificate has been trusted by navigating to the Issued Certificates folder, selecting the certificate, right click and Open.

You can see the certificate is issued by Self-Signed CA for lab.int

You then need to export this certificate. Select the Details Tab and click Copy to File.

This will launch the Certificate Export Wizard.

Select Base-64 encoded X.509 (.CER) and save the file as rui.cer into the same folder where you generated the original vCenter certificate.

Navigate to the folder and rename rui.cer to rui.crt

You then need to create a PFX file with the following command. You need to ensure the password is exactly testpassword otherwise the certificate won’t be recognised

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

It may now be a good time to replace the openssl.cfg file with the original otherwise the same DNS alias will be applied to future certificates generated.

Replacing the vCenter Certificate

You can now replace the default vCenter certificates with the new certificate files you have created.

On the vCenter Server navigate to C:\ProgramData\VMware\VMware VirtualCenter.

Make a backup copy of the SSL folder.

Copy the rui.crt, rui.key and rui.pfx files from C:\OpenSSL-Win64\bin into the into the vCenter SSL folder

In vSphere 5 there is a new way to get vCenter to use the new certificate. In vSphere 4 you needed to stop and start the vCenter Service and then re-encrypt the database connection. This has now been exposed through the vCenter API so it makes it a little easier.

Use a browser and on the vCenter Server navigate to the Managed Object Browser at the following address:

http://localhost/mob/?moid=vpxd-securitymanager&vmodl=1

Logon as an administrator of vCenter, as I use a service account I have logged on with this account.

The Managed Object Type for the vpx.SecurityManager will load, Click on reloadSslCertificate

Click on Invoke Method

The new SSL certificates will be loaded and you should see Method Invocation Result: void if it is successful.

On the vCenter Server, restart the VMware vCenter Management Webservices.

You can check the trusted certificate has been successfully replaced by pointing your browser to the https:// web server address of your vCenter server (in my example https://lonvc01.lab.int/), you should no longer see the security certificate warning message.

If you click on the padlock symbol you should be able to see the new certificate by clicking on View certificates.

On the General tab you can see the certificate has been issued by Self-Signed CA for lab.int rather than the server itself and on the Certification Path tab you can see the certificate key chain.

As you have created a certificate containing both the FQDN lonvc01.lab.int and the short name lonvc01 you should be able to launch the vSphere client with either name and no longer get any certificate warnings for the vCenter Server (you may still get warnings for other vCenter components and plug-ins which use different certificates).

Part 4 will show you how to replace the default Update Manager 5 Server Certificate.