When it comes to SSL Certificates and vCenter, there are a few options:

• Use the Self-Signed Certificates that are the default – ignore the untrusted certificate warning and go about your day
• Use the Self-Signed Certificates that are the default and Download the self-signed vCenter Certificate Chain to add it to your computer’s trusted certificate store. This makes the untrusted cert warnings go away. It is easy to manage if you have a small number of administrators.
• Make the Certificate Authority in vCenter (VMCA) a Subordinate CA to your in-house Certificate Authority.  This option replaces all certficates in your vSphere environment.  It has an important security factor which you must consider
• Replace the SSL Certificate on the vCenter front-end with a standard SSL Certificate; but allow the VMCA to self-sign certificates for each host.  This is called Hybrid vSphere SSL Certificate Replacement, and is considered by many to be the best balance of security and risk.

Why Hybrid vSphere SSL Certificate Replacement over Subordinate CA?

Making the Certificate Authority in vCenter (VMCA) a Subordinate CA to your Enterprise CA is does work.   All certificates in your vSphere environment (vCenter and hosts) will have enterprise trusted certificates.  Before deciding on this approach,  It is important to look at this from a security standpoint.

When the VMCA has a subordinate CA certificate from your Enterprise CA – it can generate certificates that are trusted by your entire enterprise.  This could allow a rogue admin or bad actor to use this powerful certificate to  create unauthorized certificates which would be trusted by your organization. You should review this in light of the security policies in your organization.

In Hybrid vSphere SSL Certificate Replacement, only the vCenter Machine SSL Certificate is replaced.  This certificate is a standard SSL Certificate and cannot be used to generate other certificates.   This still provides trust that access to vCenter Server is secure with less risk.

This method does not replace the certificates on each vSphere host with an enterprise trusted certificate; but consider the following:

• The majority of your time spent managing a vSphere environment should be using vCenter
• If a host certificate changes – this will cause issues with vCenter-host communication and should trigger an alarm
• If you absolutely need additional assurance of the host certificates, you can download the self-signed vCenter Certificate Chain and import this into your computer’s trusted certificate store.  This is a low-risk method to ensure secure communication to hosts

Replacing the Machine SSL Certificate in vCenter

Before you begin

It’s always a good idea to take a snapshot of vCenter before making significant changes like this.  Make sure you are taking a snapshot of vCenter the right way.  While you are at it – take a few moments and configure your vCenter Server Backup.

Generate the Certificate Signing Request

There are multiple ways to do this.  I prefer using OpenSSL which makes it easy for me to rinse and repeat the process as needed in my environment.

Generate a private key

openssl genrsa -out vcsa.key 2048

Create an OpenSSL config file

This can be done in any text editor.  I will name this file vcsa.cnf.  Substitute your own values

[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no

[req_distinguished_name]
C = US
ST = Ohio
L = Columbus
O = Cybersylum
OU = Cybersylum Labs
CN = vcsa.cybersylum.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
IP.1 = 172.16.1.3
DNS.1 = vcsa.cybersylum.com
DNS.2 = vcsa

Create the Certificate Signing Request (CSR)

openssl req -new -key vcsa.key -out vcsa.csr -config vcsa.cnf

This takes files created earlier and outputs file named vcsa.csr  which you can take to any Certificate Authority to obtain the SSL Certificate.  I use an internal Microsoft CA and requested a certificate using the Web Server template.

Installing the new Machine SSL Certificate

Once the new SSL Certificate has been generated, you are ready to install.  You will also need:

• The private key used in creating the CSR
• The full certificate chain from the Certificate Authority that issued the certificate.  This file should contain certificates for all CAs in the chain.

These certificates should be in the PEM format.  OpenSSL can help convert formats if needed.

Copy these 3 files to your vCenter Server Appliance.  This can be done in one of two ways

1. All of these files are simple hashed text.  You can copy and paste the exact contents into an editor running in an SSH session
2. You can SCP the files to the appliance filesystem.  I recommend putting them in /tmp.

shell.set --enabled true
shell

chsh -s /bin/bash root

Connect to the VCSA as root using SSH. Now launch the Certificate Manager

/usr/lib/vmware-vmca/bin/certificate-manager

Choose Option 1 – Replace Machine SSL Certificate.

You will see the following prompts

• password for [email protected] (or the local SSO admin in your environment)
• generate CSR or import certificate – Choose Option 2 – Import
• Path to certificate file
• Path to private key
• Path to Signing Certificate – this is the Root CA Chain file
• Confirmation to replace the Machine SSL Certificate

After you type Y and hit Enter, the VMCA will apply the new certificate and restart vCenter Services.

Once the services have restarted, you can access vCenter from your web browser and verify the new certificate is in place.  In the example below – note the details about the certificate issuer.  This is the MS Enterprise CA in my lab.

Follow up Steps

• Depending on where your certificate was issued, you may need to reconfigure any other software platforms that communicate with vCenter so they accept the new certificate.  This can include other VMware products (Aria Automation or Operations), or 3rd party products like Backup or monitoring solutions.
• Once you are satisfied that the change was successful – remember to remove the vCenter snapshot.