Accessing vCenter through a Subject Alternative Name (SAN) other than the vCSA’s FQDN
In this blog post, we will discuss how to access your vCenter through a Subject Alternative Name (SAN) other than the vCSA’s Fully Qualified Domain Name (FQDN). This is useful in situations where you want to use a different name to access the vCenter, such as a non-resolvable FQDN or a custom domain name.
To access your vCenter through a SAN other than the vCSA’s FQDN, you can add the desired SAN to the certificate and acquire secure access to the UI with it. This is achieved by using the Certificate Manager utility within the vCSA to generate the required certificates that contain the SAN name(s) in it.
Before proceeding with the procedure, it would be advisable to perform these steps in a test environment first before implementing this in production and to take a snapshot of the VM. If your certool.cfg is already in place and there is no need to change the information in this file, then you can skip this step.
To deviate from the standard information that comes with the template and change it to the values of your organization, edit the certool.cfg file located in > /usr/lib/vmware-vmca/share/config. The information provided above will return in a later stage whilst generating the root ca for the vCSA.
Proceed to login to your vCSA through ssh and start the Certificate Manager utility in the following dir > /usr/lib/vmware-vmca/bin. Select option 4 and provide the necessary information if needed. Press enter if the default value is correct.
When the Regenerate a new VMCA Root procedure is finished, a new root.cer file is created. The file is located at > /var/lib/vmware/vmca. Copy the content (BEGIN Certificate till END Certificate) of the root.cer file and paste it in a notepad file, save the file as a .cer file. In our case, the file name is > vstack.it.cer.
Depending on your Organization’s Certificate policy, the following may or may not be applicable to you. If, for instance, your organization works with GPO to distribute the certificate, you will have to arrange this first before proceeding with step 3 in the Certification Manager utility. If else, the vCenter UI will not be available to users due to the absence of the correct certificate.
For our (demonstration) purposes, we will continue to manually import the certificate in the “Trusted Root Certification Authorities” folder within certlm on our management server as described below. Install the newly created .cer certificate file Select > Open > Next Place all certificates in the following store > Browse Select “Trusted Root Certification Authorities”.
You can view the certificate in certlm. To do this, go to > Start > Run > certlm.msc. Find your cert and open it to view the properties.
Next step is to perform option 3 within the Certification Manager utility, which is “Replace Machine SSL Certificate with VMCA Certificate”. This step is important as for the SAN(s) are added here. First, the FQDN then the SAN value(s), comma separated as shown in the example text below stated in bold. Choose option 3 > “Replace Machine SSL certificate with VMCA Certificate” when step 3 is finished.
Navigate to your browser > vCenter UI > Connection security settings (lock) > and check the certificate to see if the SAN value(s) are added here. You can now access your vCenter through the newly added SAN(s), make sure that the SAN names are added in DNS.
In conclusion, accessing your vCenter through a Subject Alternative Name (SAN) other than the vCSA’s FQDN is a useful feature that allows you to use a different name to access the vCenter. By following the steps outlined above, you can add the desired SAN to the certificate and acquire secure access to the UI with it. Remember to perform these steps in a test environment first before implementing this in production and to take a snapshot of the VM.