In a production environment, it is important to use digital certificates to secure the connection between your computer and the VMware vCenter Server (VCSA) that you are trying to access.
In addition, using certificates signed by your certification authority allows you to automatically verify the identity of the server you are trying to access and thus block the connection in the event of a problem.

1. Invalid SSL certificate used by default by VMware vCenter Server (VCSA)
2. Certificate management on VMware vCenter Server (VCSA)
   1. VMware Certificate Authority (VMCA) used by default
   2. Use VMCA as a subordinate (secondary) certificate authority
   3. Use custom certificates for all VMware vSphere components
   4. Use the Hybrid model (custom certificates only for the web client)
3. Create a certificate template for the VMware vCenter Server machine certificate
4. Create the certificate request for the VMware vCenter Server machine certificate (VCSA)
5. Request a certificate from your certification authority on Windows Server
6. Obtain the private key generated by your server when requesting certificate signing
7. Replace VMware vCenter Server machine SSL certificate
8. Renew SSL certificates used internally by VMware vSphere (optional)
9. Export your certificate authority's certificate
10. New SSL certificate not taken into account
11. Update the SSL certificate used by VMware vCenter Server (VCSA)
12. Reset the machine SSL certificate (in case of problem)
13. VMware ESXi host SSL certificates considered invalid
14. Trust SSL certificates issued by the VMCA certificate authority
15. VMware ESXi host certificates considered valid

1. Invalid SSL certificate used by default by VMware vCenter Server (VCSA)

By default, when you attempt to access the web interface of your VMware vCenter Server (VCSA), a warning is displayed.
In Mozilla Firefox, you will receive the warning "Warning: Potential Security Risk Ahead".

To still access your server's web interface, click on: Advanced.

Next, Firefox will tell you that it doesn't trust [domain name or IP address of your VCSA server], because the issuer of its certificate is unknown.
The issuer corresponding to the certification authority that issued the certificate used to secure the connection to your server.
The error code displayed is: SEC_ERROR_UNKNOWN_ISSUER.

Click "View Certificate" to see the certificate in use or click "Accept the Risk and Continue" to ignore this warning.

If you click on the "View certificate" link, you will see that the certificate:

• is valid for (subject name / common name): [domain name of your VCSA server]
• was issued by the fictitious certificate authority (issuer name / common name): CA vsphere local

If you ignore this warning, your web browser will tell you that there is a problem with securing the connection to this server.
Log in as: administrator@vsphere.local.

Once connected, you will be able to access the VMware vSphere Client will appear.

Go to the menu and click on: Administration.

In the left menu that appears, click on: Certificates -> Certificate Management.
On the "Certificate Management" page that appears, indicate:

• Server IP/FQDN: "localhost" to manage certificates for the VMware vCenter Server (VCSA) you are currently on or the IP address or domain name of the desired VMware vCenter Server (VCSA) .
  In our case, we indicated the domain name of our VMware vCenter Server (VCSA): vcsa.informatiweb.lan.
• Username: the username of a user authorized to manage certificates on the desired server.
  In this tutorial, we will use the "administrator@vsphere.local" account created during the installation of VMware vCenter Server (VCSA).
• Password: the password for the user account specified above

Then click on the button: Login and manage certificates.

To secure access to your VMware vCenter Server (VCSA) and more specifically to its VMware vSphere Client, you will need to replace the machine SSL certificate displayed at the top of the page.
Click the "View details" link for the "__MACHINE_CERT" certificate.

Note: the "View certificates in another ..." button at the top of the page is a button allowing you to disconnect from this page to return to the form in the previous image.

As you can see, this "__MACHINE_CERT" certificate is:

• Common name: valid for the fully qualified domain name (FQDN) of your VMware vCenter Server (VCSA) that you use to connect to that server's web interface
• Issued by: issued by a fictitious certificate authority named "CA".

2. Certificate management on VMware vCenter Server (VCSA)

2.1. VMware Certificate Authority (VMCA) used by default

By default, on VMware vCenter Server (VCSA), you will find a "VMCA" certification authority (VMware Certificate Authority) which allows you to manage all the certificates of your VMware vSphere infrastructure (VMware ESXi hosts, VMware vCenter Server (VCSA) servers, ...).
The certificates generated and the private keys associated with them emanate from this "VMCA" certification authority used internally by your VMware vSphere infrastructure. All data from your VMCA certification authority (machine SSL certificates, solution certificates, trusted root certificates, private keys, ...) is stored in the VMware Endpoint Certificate Store (VMware Endpoint Certificate Store / VECS).

Since the VMCA certificate authority created by default on your VMware vCenter Server (VCSA) is not a certificate authority recognized by all computers and servers worldwide, all certificates that emanate from it are considered invalid (unreliable). Except for your VMware vCenter Server (VCSA) since the certificate of this VMCA certificate authority is present in the "Trusted Root Certificates" section of it.
Note that the common name of this VMCA certification authority visible in your server's certificate management is "CA" and not VMCA.

To learn more about the VMware Endpoint Certificate Store (VECS), visit the official VMware documentation : VMware Endpoint Certificate Store Overview.

When you want to secure access to your VMware vCenter Server (VCSA) and more particularly its web client (VMware vSphere Client), you have several options:

• Use VMCA as a subordinate (secondary) certificate authority
• Use custom certificates for all VMware vSphere components
• Use the Hybrid model (custom certificates only for the web client)

2.2. Use VMCA as a subordinate (secondary) certificate authority

The first option to secure access to your VMware vSphere virtual infrastructure is to make the VMware VMware Certificate Authority (VMCA) become a subordinate (secondary) certification authority of your own root certification authority.

Because the new certificate for this VMCA CA will come from your own CA, any certificates it generates will be considered valid for computers and servers that already trust your own root CA.
However, this also means that a malicious administrator of your VMware vSphere virtual infrastructure could also generate valid certificates within your company for other computers or servers outside of your VMware vSphere infrastructure.
This technique therefore greatly simplifies the management of certificates, but can pose security problems.

This method is therefore very rarely if ever used.

2.3. Use custom certificates for all VMware vSphere components

A VMware vSphere virtual infrastructure is always composed of several servers and mainly:

• VMware ESXi hosts: hypervisors on which your virtual machines run
• VMware vCenter Server (VCSA) servers: servers that allow you to manage your virtual machines, your VM templates, your OVF templates, ...
• and more

If you want to use custom certificates for all components of your VMware vSphere infrastructure, you will therefore need to generate certificates for all your VMware ESXi hosts, your VMware vCenter Server (VCSA) servers, but also for the solutions used internally by vCenter Server.

This can quickly become difficult to manage, depending on the number of VMware ESXi hosts and VMware vCenter Servers (VCSA) servers in your VMware vSphere virtual infrastructure. Especially since this also means that you will have to submit dozens or even hundreds of certificate requests (CSR) to your own certificate authority.

This method is the most secure, but as noted previously, it can quickly become unmanageable depending on the size of your VMware vSphere virtual infrastructure. Additionally, all generated certificates will also need to be replaced when they are about to expire.

2.4. Use the Hybrid model (custom certificates only for the web client)

To best secure your VMware vSphere virtual infrastructure and facilitate the management of its certificates, a new hybrid model has been born with VMware vSphere 6.0.

As you see in the image below, with this hybrid model, you will use:

• custom certificates (from your own certification authority) only for the web client (VMware vSphere Client) of your VMware vCenter Servers (VCSA).
  This will allow you to better secure access to your VMware vSphere infrastructure via your VMware vCenter Server (VCSA) servers.
• certificates from the VMCA certificate authority of your VMware vSphere virtual infrastructure for solution certificates and SSL certificates used on the various VMware ESXi hosts connected to your VMware vCenter Servers (VCSA)
  Which poses almost no problem since, since VMware vSphere 6.0, a reverse proxy has been added to VMware vCenter Server. Which means that all services using these certificates only communicate with each other.
  Inside your VMware vSphere infrastructure, the certificates used are therefore considered valid for these different services.
  Additionally, in a production environment, direct access to your VMware ESXi hosts is often blocked using normal or strict locking mode.
  If necessary, you can choose to consider the VMCA certification authority certificate as reliable in your company as explained towards the end of this tutorial.

This method is the most practical, because it allows you to benefit from security while making it easier to manage your SSL certificates.
It is therefore this method that we will use in this tutorial.

If you would like more information about the VMCA certificate authority and the different certificate management methods under VMware vSphere, refer to the "New Product Walkthrough – Hybrid vSphere SSL Certificate Replacement" page of the official VMware blog.