Previously, we explained how to secure a VMware VCSA server (VMware vCenter Server).
This time, we will explain how to secure VMware VCSA servers (VMware vCenter Server) in a multi-site infrastructure.

1. Certificate problem
2. Create the multi-site Active Directory infrastructure
3. Create the VMware vCenter Server infrastructure (ELM mode)
4. Deploy multi-site PKI infrastructure
5. Create a certificate template for the VMware vCenter Server machine certificate
6. Create the certificate request for the VMware vCenter Server machine certificate (VCSA)
7. Replace VMware vCenter Server Machine SSL certificate
8. Renew SSL certificates used internally by VMware vSphere (optional)
9. Export the certificate of your certification authorities
10. Add your certificate authorities' certificate to your vCenter Server's trusted root certificates (VCSA)
11. Update the SSL certificate used by VMware vCenter Server (VCSA)
12. VMware ESXi host SSL certificates considered invalid
13. Trust SSL certificates issued by the VMCA certificate authority
14. VMware ESXi host certificates considered valid

1. Certificate problem

As you already know, by default, when you access a VMware VCSA server (VMware vCenter Server), a warning appears.

As you can see, this warning appears because the issuer of the certificate is unknown given that the certificate used by default is self-signed.

2. Create the multi-site Active Directory infrastructure

For this tutorial, we will first deploy a multi-site Active Directory infrastructure to simulate a company headquartered in Brussels (Belgium) and which also has offices in Paris (France).

3. Create the VMware vCenter Server infrastructure (ELM mode)

Once the multi-site Active Directory infrastructure is deployed, deploy your VMware vCenter Server infrastructure using ELM (Enhanced Linked Mode).

4. Deploy multi-site PKI infrastructure

For the certificate used to protect your VMware VCSA server (VMware vCenter Server) to be valid, it must come from a trusted certificate authority.
However, in larger companies, you will use a root certificate authority (offline) and several secondary certificate authorities (for example: one per country, or even one per department for security reasons).

In our case, we deployed:

• the root certificate authority at our company headquarters.
  In our case: in Brussels (in Belgium).
• a secondary certification authority in each country where our company is present.
  In other words, in our case, a secondary certification authority in Brussels (in Belgium) and another in Paris (in France).

To do this, refer to our tutorial: Deploy a multi-site PKI infrastructure on Windows Server 2016.

5. Create a certificate template for the VMware vCenter Server machine certificate

Now that you have a multi-site infrastructure with the necessary Active Directory, VMware and PKI servers across your various physical sites, you can move on to securing your VMware infrastructure.
To do this, on one of your secondary certification authorities, open the "Certification Authority" console and right-click "Manage" on "Certificate Templates".

In our case, we will start with our secondary certification authority "InformatiWeb Sub CA (Brux)" located at our company headquarters in Brussels (Belgium).

When you deploy PKI in a multi-site Active Directory infrastructure, the certificate templates for your secondary certificate authorities are stored in Active Directory.
If you look in the left column, you can see that the Certificate Templates Console is connected to one of your domain controllers.
However, the domain controller chosen by default is not necessarily the one corresponding to the Active Directory site where your current secondary certification authority is located.

As you can see, in our case, this console connected to our Active Directory domain controller "brux-dc2" located in Brussels (Belgium).

To connect to another Active Directory domain controller, right-click "Certificate Templates ([AD domain controller name]) -> Connect to another writable domain controller".

Note: the certificate templates available on a domain controller are generally the same since the data in your Active Directory infrastructure is automatically replicated between your different domain controllers on a periodic basis.
But since replication is not instantaneous, there may be some differences if you just made changes to a particular domain controller.

In our case, since we are on our secondary certificate authority of Brussels, we will select the domain controller "brux-dc1".
Which also avoids using the WAN link. Which will improve performance just in case.

Now we can see in the left column that we are connected to our domain controller "brux-dc1".
Duplicate the “Web Server” certificate template.

Create the "vSphere 6.x" certificate template (based on the existing default "Web Server" certificate template) by referring to step "3. Create a certificate template for the VMware vCenter Server machine certificate" of our tutorial on securing access to VMware vCenter Server Appliance (VCSA) over HTTPS.

Once the "vSphere 6.x" certificate template has been created, you will see it appear in the list.

As usual, to be able to issue certificates using your new certificate template, you must add this new template to the list of certificate templates to issue.
To do this, right-click “New -> Certificate Template to Issue” on “Certificate Templates”.

Select the "vSphere 6.x" template and click OK.

The "vSphere 6.x" certificate template appears in the "Certificate Templates" folder.

Now that the new vSphere 6.x model is created on the secondary certification authority of your company's headquarters, go to the certification authority of your 2nd physical site (in our case that of Paris).
Open the "Certificate Authority" console on this remote CA and right-click "Manage" on "Certificate Templates".

As you can see, despite being on the Paris CA (in our case), the certificate templates console is connected to our domain controller "brux-dc2".
Indeed, we only have one Active Directory domain (replicated from one physical site to another with the same SID domain) and the data is therefore shared by the different physical sites.

To connect to a local domain controller, right-click "Connect to another writable domain controller" on "Certificate Templates ([DC name])".

Choose a domain controller that is on the same physical site as the certificate authority where you are located.
In our case, given that we are on our certification authority "InformatiWeb Sub CA (Paris)", we select our domain controller "paris-dc1".

Now this certificate templates console is connected to our domain controller "paris-dc1".
However, you will notice that the new "vSphere 6.x" certificate template that you have just created from the other physical site (in our case: in Brussels) will not appear.

Rather than waiting for Active Directory to replicate this new certificate template to your remote physical site, we recommend that you force data replication from the domain controller that is already up to date.
In our case, we had created this template from the certificate authority located in Brussels and the certificate template console was connected to our domain controller "brux-dc1".
Which means that our domain controller "brux-dc1" has this new certificate template "vSphere 6.x".

To replicate this certificate model to the remote physical site (in Paris in our case), use the "Active Directory Sites and Services" console on one of your domain controllers and select the "NTDS Settings" node located in the "[name of remote DC to update]".
In our case, we are going to update our "paris-dc1" domain controller from our "brux-dc1" domain controller.

Wait a little (up to 1 minute, if necessary), then refresh the list of certificate templates available on your remote certificate authority.
As you can see, in our case, on our Paris CA, by connecting this console to our domain controller "paris-dc1", we can see that the certificate template "vSphere 6.x" has appeared.

To use this new certificate model from your remote site (Paris in our case), simply add it to the list of certificate models that your remote certificate authority (InformatiWeb Sub CA (Paris) in our case) can issue.

To do this, right-click “New -> Certificate Template to Issue” on the “Certificate Templates” folder.

Select the "vSphere 6.x" certificate template and click OK.

The new “vSphere 6.x” certificate template to be issued appears.

On one of your domain controllers, open the "Active Directory Sites and Services" console and click: View -> Show Services Node.

Next, go to the “Services -> Public Key Services -> Certificates Templates” folder and you will see that your new “vSphere 6.x” certificate template is there.
Which shows you that the certificate templates are stored in Active Directory and are therefore accessible from all certificate authorities in your Active Directory domain.
However, each certificate authority can issue different or the same certificate models if desired.

You can also see this same certificate model in your Active Directory by exploring its "Configuration" partition using the "ADSI Edit" console.
In this case, go to "CN=Configuration,... -> CN=Services -> CN=Public Key Services -> CN=Certificate Templates" and you will find objects of type "pKICertificateTemplate", including your certificate template " CN=vSphere6.x".