I am currently deploying a VMware Validated Design for SDDC at a customer, with the addition of vRealize Network Insight. This blogpost explains how to use the Certificate Generation Utility for VMware Validated Design for Software-Defined Data Center (CertGenVVD utility) to replace the default SSL certificate of the vRNI Platform Appliance. CertGenVVD is a command-line utility that you can use to generate custom certificates for the products that you use to build a Software-Defined Data Center (SDDC). I’m not going to cover the prerequisite steps required to setup a CA and the CertGenVVD Utility itself. For more information, please refer to https://kb.vmware.com/s/article/2146215 and the VVD Planning and Preparation Guide (page 34 of VVD 4.3).
Creating the config file
The CertGenVVD utility uses two config files. A “Default.txt” file and specific config files in the ConfigFiles folder inside the CertGenVVD folder. Default.txt contains default values for the attributes Organization, Organization Unit, Location, State, Country, Common Name and Certificate Key Size for CSR generation. In our case we will only place a single config file for vRNI inside the ConfigFiles folder:
The content of both files is of course specific to your environment, but the sample files provided with the CertGenVVD should give you some solid guidance. Here are the files I used in my homelab environment. Ensure the files don’t contain trailing spaces, tabs or anything similar!
ORG=Homelab OU=Homelab.local LOC=Homelab ST=NH CC=NL CN=VMware_VVD keysize=2048
[CERT] NAME=default ORG=default OU=default LOC=default ST=default CC=default CN=vrni-01a.homelab.local keysize=default [SAN] vrni-01a vrni-01a.homelab.local
Generating the custom certificate
If you have configured both config files correctly, and your environment is setup following the CertGenVVD requirements and guidelines, the following Powershell command will create a folder named SignedByMSCACerts and generate SSL certificates in multiple formats according to the certificate requirements of the SDDC management components:
.\CertGenVVD-3.0.2.ps1 -MSCASigned -attrib 'CertificateTemplate:VMware'
Analyzing the output
After you provide the P12 keystore password, the output of the CertGenVVD utility is:
The readme.txt contains a clear description of all the files:
vrni-01a.key Private Key vrni-01a.1.cer Base 64 encoded. Certificate only. vrni-01a.2.chain.pem Base 64 encoded. Private key, cert, and Root cert. vrni-01a.3.pem Base 64 encoded. Certificate and Root cert without private key. vrni-01a.4.p12 P12 format. Private key, cert, and Root cert with encryption. vrni-01a.5.p12 P12 format. Private key, cert with encryption. vrni-01a.6.p7b P7b format.cert and Root cert.
Getting the relevant files to the vRNI Platform Appliance
As per https://kb.vmware.com/s/article/2148128, vRNI requires the full certificate chain with private key, both base64 encoded PEM format. This means we are looking at the vrni-01a.key and vrni-01a.2.chain.pem files. Now, vRNI was acquired from a company called Arkin, so the appliance interface and CLI is a bit different from other SDDC components. We can’t SCP the files directly to the appliance. Instead we have to put the files on a Linux host and use the custom-cert copy command directly from the vRNI CLI. If you don’t have a Linux host at your disposal, you could put them on one of your ESXi hosts (thanks for the tip @wessieloerus! See his original blogpost here by the way!).
Installing the new certificate
In my homelab, I took the following steps:
- I copied the files vrni-01a.2.chain.pem and vrni-01a.key to the /tmp folder of ESXi host esxi-01a
- I renamed the files to vrni.crt and vrni.key
- Logged into the vRNI CLI, I first removed the current SSL certificate: custom-cert remove
- I then copied the files using the commands
- custom-cert copy –host esxi-01a –user root –port 22 –path /tmp/vrni.crt
- custom-cert copy –host esxi-01a –user root –port 22 –path /tmp/vrni.key
- I then applied the new SSL certificate using the custom-cert apply command. After a few moments, the new SSL was successfully applied and my HTTPS connection is secure!