The work required for setting up or updating your 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.
Administrators Who Do Not Replace VMware Certificates
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 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.
Administrators Who Replace VMware Certificates with Custom Certificates
If your company policy requires certificates that are signed by a third-party or enterprise CA, 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 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 the user performs 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. Replacing solution user certificates is often not required by a company policy.
You can use the command-line utility, vSphere Certificate Manager, for most certificate management tasks.
vSphere Certificate Interfaces
|vSphere Client||Perform common certificate tasks with a graphical user interface.|
|vSphere Automation API||See VMware vSphere Automation SDKs Programming Guide.|
|Certificate Manager utility||Perform common certificate replacement tasks from the command line of the vCenter Server installation.|
|Certificate management CLIs||Perform all certificate management tasks with dir-cli, certool, and vecs-cli.|
|sso-config utility||Perform STS certificate management from the command line of the vCenter Server installation.|
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 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.