Certificate management in VMWARE
Exchange certificates in the VM-Ware Software-defined Data Center and VShpere Data Center
Over time, certificates have become very important in a vSphere environment as they ensure that communication between services, different VMware products and users is secure and that the systems are who we think they are.
By default, the VMCA* runs with the self-signed certificate as the root CA for all vSphere products/components. If this certificate is not distributed on the desktops as the root CA certificate, we receive a browser security warning.
In general, certificates are used for the encryption of communication, the authentication of vSphere services or for internal actions such as the signing of tokens. Therefore, IT security departments often request to replace VMware certificates with other (trusted) certificates.
In this blog post, four certificate management methods supported by VMware are analyzed so that the appropriate method can be selected for the implementation in the respective context.
The prerequisite for three of the four methods described here is that a two-tier Microsoft PKI is already in place.
VMWARE: Supported methods for certificate management
In vSphere it is possible to perform certificate management using four different methods:
1. fully managed mode (default mode with self-signed root certificate)
In this case, the VMCA has a new root CA certificate that was created during the installation. With this certificate, vCenter Server manages the intra-cluster certificates that hosts use to communicate with each other and with the vCenter Server. There is also a machine certificate that is used when the user logs on to the vSphere Client. The VMCA root CA certificate can be downloaded from the vCenter Server/PSC main page and imported to other PCs to establish trust. The certificate can be regenerated and it is also possible to replace the default information with your own information.
2. hybrid mode
In this “hybrid” approach, custom certificates are used for the machine SSL certificates of the Platform Services Controller and the vCenter Server VMs, but the VMCA remains responsible for managing the solution user and ESXi host certificates. This means that the ESXi host certificates remain untrusted.
With this method of certificate lifecycle management, the VMCA is not used as a subordinate certification authority. This allows the VMCA to act as an independent CA and issue the internal Solution User and ESXi host certificates.
3. subordinate mode
In this case, the VMCA can operate as a trusted subordinate CA, which is a delegated authority of an enterprise CA. The vCenter Server/PSC can still automate the certificate management for the new VMware components (on the old VMware components the certificates need to be swapped - but this approach is quite simple), and the generated certificates will be trusted as part of the organization.
The following must be noted with this method:
The certificate and private key are stored in the file system, not in a protected certificate store. This allows all users with shell access to use the certificate and private key.
4. full custom mode
In this mode, the VMCA is not used at all. An administrator must install and manage all certificates within the vSphere cluster - manually. It is not difficult to imagine how time-consuming this is.
WHAT OPTIONS ARE AVAILABLE ON THE VMWARE SDDC MANAGER?
Only the machine SSL certificates (for web-based vSphere clients and SSO login pages) from an MS PKI can be managed on the VMware SDDC Manager. Unfortunately, the solution certificates used for communication encryption, service authentication and token signing cannot be managed. To manage the machine SSL certificates from the SDDC Manager, a direct connection between the SDDC Manager and the Subordinate CA is not absolutely necessary, but the certificate exchange procedure without a connection to the Subordinate CA is significantly more complicated and time-consuming.
In addition to the corresponding certificate templates, an IIS web service with “Basic Authentication” must be configured on the Subordinate CA and the “certsrv” website must be accessible via the HTTPS protocol. In addition, a service account is required with which the corresponding authorizations on the VCF certificate template (read and enroll) must be created in MS AD.
The certificates on the ESXi host cannot be exchanged by the SDDC Manager, but either by ESXi Shell on each ESXi host or by the “Subordinate Mode” method mentioned above.
It is important to know that the following problems can occur after exchanging the certificates with the Subordinate or Fully Custom method, but these can be solved relatively easily:
- The connection of the NSX-T Manager with the vCenter was interrupted
- The connection of the NSX-V Manager with the vCenter and PSC was interrupted
- The vSAN could not be managed
These problems have no influence on the accessibility of the VM.
CONCLUSION
If you take a close look at all the methods, it is clear that the Subordinate Mode method and the Fully Custom method fulfill all security requirements. For companies that only want to eliminate browser security warnings, the Hybrid Mode method is an optimal solution. With the Subordinate Mode method, and indeed any other method, certificates are not automatically replaced when they expire.
Finally, the only thing left to say is: Although VMware, since vSphere version 6.x has simplified certificate management, there is still no fully automated certificate management method.
*The VMware Certification Authority
Learn more
VMware acquisition by Broadcom: Discover alternatives to cut costs and reduce dependencies!
vSphere with Tanzu: Introduction and implementation
In the virtualization of infrastructures, you sometimes reach the limits of what is possible. But workarounds are often possible.
Muhamed Ahmovic
Technischer Presales
Phone: +49 172 629 6400
E-Mail: mahmovic@spirit21.com
Muhamed is responsible for the design, planning and implementation of IT solutions with a focus on VMware, Storages and Microsoft. If you have any questions about encryption technologies, you’ve come to the right place.
