10.2 Certificate Configuration and Usage
On any production platform, the self-signed certificates generated when you install the components must always be replaced with those from a verifiable trusted Certificate Authority (CA) to enable certificate verification on all internal vSphere and external client connections.
Self-signed certificates are vulnerable to man-in-the-middle attacks and are unlikely to comply with your organization’s security policy. In vSphere 6.0, the Platform Services Controller hosts the VMware Certificate Authority (VMCA) and the VMware Endpoint Certificate Store (VECS). The VMCA and VECS are part of the Platform Services Controller, and take full advantage of the multi-master replication model that is offered by the Directory Service (VMDir) to provide high availability.
The VMCA is a Certificate Authority that allows you to:
• Generate certificates
• Generate CRLs
• Use the UI
• Use the command-line interface to replace certificates
The VECS is where the certificates within the Platform Services Controller are stored, with exception of the ESXi certificates, which are stored locally on the individual vSphere hosts. The VECS can:
• Store certificates and keys
• Sync trusted certificates
• Sync CRLs
• Use the UI
• Use the command-line interface to perform various actions
In previous vSphere releases, every service had its own user and as such required its own certificate. However, this is no longer the case because vSphere now uses solution users. In vSphere 6.0, there are four main solution users that hold the certificate used for a number of services.
Figure 36. Certificate Solution Users
The VMCA can pose as either a root certificate authority or a subordinate certificate authority that issues signed certificates to all vSphere 6.0 components through the solution users. This secures the environment by using a centralized CA to generate certificates, as opposed to using self-signed certificates as in previous releases.
Because the VMCA can also be configured as a subordinate CA, it provides the ability to issue certificates based on an existing enterprise PKI. Because most service providers and enterprises already have an existing key infrastructure, non-disruptively adding the VMCA as a subordinate protects the investment already made. Allowing service providers that already have an investment in a PKI to incorporate the VMCA into their existing infrastructure adds a level of integration over certificate management that is applicable to a large number of use cases, including simplifying certificate lifecycle management in the vSphere environment.
Additional VMCA use cases are illustrated in the following figure.
Figure 37. VMware Certificate Authority Use Cases
