The work required for setting up or updating your vSphere certificate infrastructure depends on the requirements in your environment. You must consider whether you are performing a fresh install or an upgrade, and whether you are considering ESXi or vCenter Server.
Environments That Use VMware Certificate Authority Certificates
VMware Certificate Authority (VMCA) can handle all certificate management. VMCA provisions vCenter Server components and ESXi hosts with certificates that use VMCA as the root certificate authority. If you are upgrading to vSphere 6.0 or later from an earlier version of vSphere, all self-signed certificates are replaced with certificates that are signed by VMCA.
If you do not currently replace VMware certificates, your environment starts using VMCA-signed certificates instead of self-signed certificates.
Environments That Use Custom Certificates
If your company policy requires certificates that are signed by a third-party or enterprise certificate authority, or that require custom certificate information, you have several choices for a fresh installation.
- Have the VMCA root certificate signed by a third-party CA or enterprise CA. Replace the VMCA root certificate with that signed certificate. In this scenario, the VMCA certificate is an intermediate certificate. VMCA provisions vCenter Server components and ESXi hosts with certificates that include the full certificate chain.
- If your company policy does not allow intermediate certificates in the chain, you can replace certificates explicitly. You can use the vSphere Client, vSphere Certificate Manager utility, or perform manual certificate replacement using the certificate management CLIs.
When upgrading an environment that uses custom certificates, you can retain some of the certificates.
- ESXi hosts keep their custom certificates during upgrade. Make sure that the vCenter Server upgrade process adds all the relevant root certificates to the TRUSTED_ROOTS store in VMware Certificate Endpoint Store (VECS) on the vCenter Server.
After the upgrade to vSphere 6.0 or later, you can set the certificate mode to Custom. If the certificate mode is VMCA (the default), and you perform a certificate refresh from the vSphere Client, the VMCA-signed certificates replace the custom certificates.
- For an upgrade of a simple vCenter Server installation to an embedded deployment, vCenter Server retains custom certificates. After the upgrade, your environment works as before. The existing vCenter Server and vCenter Single Sign-On certificates are retained. The certificates are used as machine SSL certificates. In addition, VMCA assigns a VMCA-signed certificate to each solution user (collection of vCenter services). The solution user uses this certificate only to authenticate to vCenter Single Sign-On. VMware does not recommend replacing solution user certificates.
vSphere Certificate Interfaces
|Perform common certificate tasks with a graphical user interface.
|vSphere Automation API
|See VMware vSphere Automation SDKs Programming Guide.
|vSphere Certificate Manager utility
|Perform common certificate replacement tasks from the command line of the vCenter Server installation.
|vSphere Certificate Management CLIs
|Perform all certificate management tasks with dir-cli, certool, and vecs-cli.
|Perform STS certificate management from the command line of the vCenter Server installation.
|PowerCLI 12.4 (requires vSphere 7.0 or later)
|Perform trusted certificate store management, manage vCenter Server Machine SSL certificates, and manage ESXi Machine SSL certificates.
For ESXi, you perform certificate management from the vSphere Client. VMCA provisions certificates and stores them locally on the ESXi host. VMCA does not store ESXi host certificates in VMDIR or in VECS. See the vSphere Security documentation.
Supported vCenter Server Certificates
For vCenter Server and related machines and services, the following certificates are supported:
- Certificates that are generated and signed by VMware Certificate Authority (VMCA).
- Custom certificates.
- Enterprise certificates that are generated from your own internal PKI.
- Third-party CA-signed certificates that are generated by an external PKI such as Verisign, GoDaddy, and so on.
Self-signed certificates that were created using OpenSSL in which no Root CA exists are not supported.