Replacing the SSL Certificate for Microsoft CA Signed on vCenter Log Insight 1.5 Virtual Appliance

Replacing the self-signed certificate of any product with a CA Signed alterative is common place and in most security conscious organizations mandatory, whilst working on an internal project recently I attempted to achieve just that for my vCenter Log Insight Virtual Appliance.

The official VMware documentation posted here, in my opinion is very light in content on this subject in fact it only really describes how to replace the certificate by browsing for the .pem file and restarting the appliance. I’m no expert when it comes to SSL Certificates and so the whole process was a little bit of trial an error but thought I would share the process with the community in an effort to save others some time.

Firstly, there are some specific requirements which are well documented these are:

• The certificate file must contain both a valid private key and a valid certificate chain.

• The private key is generated by the RSA or the DSA algorithm.

• The private key is not encrypted by a pass phrase.

• If the certificate is signed by a chain of other certificates, all other certificates are included in the certificate file that you plan to import.

• The private key and all the certificates that are included in the certificate file are PEM-encoded. Log Insight does not support DER-encoded certificates and private keys.

• The private key and all the certificates that are included in the certificate file are in the PEM format. Log Insight does not support certificates in the PFX, PKCS12, PKCS7, or other formats.

For the whole process I will be using OpenSSL tool for Windows, which I have installed to the C:\OpenSSL folder.

I also use the C:\Certs folder to store the files being generated throughout the process, if you have ever read one of the VMware KB articles this will look familiar.

The end to end process can be split into following three stages, which is pretty standard of all VMware products where you want to replace the self-signed certificate:

Stage 1 – Generating the .csr file

1. Launch a command prompt and navigate into the OpenSSL directory.

2. In the C:\Certs folder, create a folder for your Log Insight certificate files (C:\Certs\Log-Insight)

3. Open a text editor on the system where OpenSSL is installed. Create a configuration file vCenter Log Insight containing the following values (items in red must be altered to match your environment), save the file.

[ 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

[ v3_req ]
basicConstraints = CA:false
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:hostname, IP: xx.xx.xx.xx, DNS: hostname.domain.com

[ req_distinguished_name ]
countryName = UK
stateOrProvinceName = London
localityName = London
0.organizationName = VMware
organizationalUnitName = vCenter Log Insight
commonName = hostname.domain.com

4. Generate the .csr file by running the following command:

openssl req -new -nodes -out C:\Certs\Log-Insight\rui.csr -keyout C:\Certs\Log-Insight\rui-orig.key -config C:\Certs\Log-Insight\openssl-loginsight.cfg

5. Convert the orig_rui.key into RSA format by running the following command:

openssl rsa -in C:\Certs\Log-Insight\rui-orig.key -out C:\Certs\Log-Insight\rui.key

Stage 2 – Obtaining the Certificate

Now you have your .csr file, using the Microsoft Certificate Authority generate your certificate file. I've not documented the process as this is document in many other blog posts, for reference take a look at Derek Seaman's blog here.

Stage 3 – Installing the Certificate

1. Launch a command prompt and navigate into the OpenSSL directory.

2. Next we need to merge the certificate, private key and CA Chain by generating a .pfx file by issuing the following command:

openssl pkcs12 -export -in C:\Certs\Log-Insight\rui.crt -inkey C:\Certs\Log-Insight\rui.key -certfile C:\Certs\Root64.cer -name rui -passout pass:testpassword -out C:\Certs\Log-Insight\rui.pfx

3. Now we need to convert the .pfx file into the format that the vCenter Log Insight Appliance accepts which is a .pem file by issuing the following command:

openssl pkcs12 -nodes -in C:\Certs\Log-Insight\rui.pfx -out C:\Certs\Log-Insight\rui.pem

4. Finally, you need to upload the rui.pem file into the appliance as per the VMware documentation.

Limiting VMs per request within the vCAC 5.2 Self-Service portal

Ever wanted to limit the number of VMs being requested via the Self Service portal per request.  I had a customer who wanted to do this recently, their use case was to prevent user input mistakes when requesting services. The default value in vCAC 5.x is 999.

Just to be clear this is not limiting the number of VMs a user can request based on a blueprint as a total or setting the number of VMs on a reservation.

NOTE: This procedure needs to be performed on all Web Servers if you have multiple deployed.

1.       Browse to the folder D:\Program Files (x86)\VMware\vCAC\Self-Service Portal\Views\Shared

2.       Make a copy of the ‘SpinEditRow.cshtml’ file and call it ‘SpinEditRow - vCAC 5.2 Original’

3.       Edit the ‘SpinEditRow.cshtml’ file and amend the following line located on line 7:

From:             var spinnerMaxValue = this.Model.MaxValue.HasValue ? this.Model.MaxValue.Value : 999;

To:                 var spinnerMaxValue = this.Model.MaxValue.HasValue ? this.Model.MaxValue.Value : 5;

Then test the process of making a new request from the Self-Service portal, the ‘# of machines:’should now be restricted to a maximum of 5

NOTE: This is not officially support by VMware and carful consideration should be given before making this alteration. An upgrade of vCAC 5.2 would alter this change back to its default value.

vCenter Upgrade to v5.x Failed - Useful Tips

Recently I had some fun and games with what should have been a pretty routine process of upgrading a customer’s vCenter 4.1 Server to vCenter 5.0 Update 1, as it turned out it was far from straightforward.

The main background to my issue was that when performing the upgrade of the database, the progress bar did not move after twenty minutes, which indicated that there was an issue somewhere. There are various VMware KB available in relation to the symptoms I observed but none that actually provided the solution. As a general rule before proceeding with an upgrade I would recommend the following:

- Check the Database Size and reduce where you can (The customer in question had a DB of 74GB and Transaction Log of 236GB)

- Run the upgrade logged in as the Service Account used to start the vCenter Services

- Elevate the Database account to ‘sysadmin’ for the purposes of the upgrade only

Some suggested VMware KB Articles include: Database Size 1007453, Upgrade Issues 2011533, 1003960, 1025139

vCloud Automation Center 5.x – Resource Intensive Limits

To help manage your vCAC implementation and the resources on which it depends, vCAC by default places limits on the number of concurrent instances of two particularly resource-intensive operations, machine provisioning and data collection. During a recent vCloud Suite implementation this particular default behavior caught my colleagues and I out as throughput when testing was very slow. On further investigation we established that the default value was two (2).

For our implementation, we were looking to ensure the largest amount of throughput we could possible achieve without unnecessary impact to the platform. We have successfully tested setting this limit to eight (8) which allows eight machines to be provisioned at once. In order to amend this value here’s what you need to do:

1. Log into your vCAC Server where the vCAC Manager Service (vCloud Automation Center) is running

2. Locate the file ‘MachineService.exe.config’ file which can be located in the following directory ‘%SystemDrive%\Program Files x86\DynamicOps\DCAC Server’

3. Locate the following value ‘MaxOutstandingResourceIntensiveWorkItems’ and amend the value to the desired requirement

4. Save the file

5. Restart the ‘vCloud Automation Center’ service

Remember if you’re running a High Availability implementation to amend the setting on the ‘Stand-by’ system.

Enabling PowerShell Functions with SRM - DR of the Cloud

When calling PowerShell functions as part of an SRM (5.1) recovery plan, you need to perform some additional configurations within PowerShell. This can be achieved using the following procedures.

Step 1 - Set the execution level

1. Launch the 32-bit version of PowerShell

2. Run the command 'Set-ExecutionPolicy RemoteSigned'.

Step 2 - Create and configure a PowerShell profile

1. Run the command 'Test-Path $profile', this will verify if a profile already exists for the user. (assuming that one does not exist go to step 2)

2. Run the command 'New-Item $profile -type file -force', this will force the creation of a new profile file.

3. Run the command 'Notepad $profile', this will open the new file in a Notepad session.

4. Enter the following syntax into the file, then save and close:

   Import-Module vCloudDR

   Add-PSSnapin -name VMware.VimAutomation.Core

Next time you start a new PowerShell session, it will load in our custom functions from the vCloudDR module and add in the VMware core cmdlets.

Step 3 - Install the custom modules for PowerShell to call

1. Locate the folder path 'C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules'

2. Create a new folder called 'vCloudDR'. NOTE: This folder name must match the name used for the Import-Module command used in the profile in Step 2.

3. Copy your custom module file into the newly created folder

4. To test that the module has been loaded correctly, restart PowerShell and run the command 'Get-Module -ListAvailable' and verify your custom module is listed.