The impact of the new certificate infrastructure depends on the requirements in your environment, on whether you are performing a fresh install or an upgrade, and on whether you are considering ESXi or vCenter Server.
Administrators Who Do Not Replace VMware Certificates
If you are an administrator who does not currently replace VMware certificates, VMCA can handle all certificate management for you. 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.
Administrators Who Replace VMware Certificates with Custom Certificates
For a fresh installation, administrators have these choices if company policy requires certificates that are signed by a third-party or enterprise certificate authority or requires custom certificate information.
- Replace the VMCA root certificate with a CA-signed certificate. In this scenario, the VMCA certificate is an intermediate certificate of this third-party CA. VMCA provisions vCenter Server components and ESXi hosts with certificates that include the full certificate chain.
- If company policy does not allow intermediate certificates in the chain, you have to explicitly replace certificates. You can use the 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 certificate to the TRUSTED_ROOTS store in VECS on the vCenter Server.
After the vCenter Server upgrade, administrators can set the certificate mode to Custom (see Change the Certificate Mode). If certificate mode is VMCA, the default, and the user performs a certificate refresh from the vSphere Web Client, the VMCA-signed certificates replace the custom certificates.
- For vCenter Server components, what happens depends on the existing environment.
- If you upgrade a simple installation to an embedded deployment, vCenter Server custom certificates are retained. After the upgrade, your environment will work as before.
- If you upgrade a multi-site deployment where vCenter Single Sign-On is on a different machine than other vCenter Server components, the upgrade process creates a multi-node deployment that includes a Platform Services Controller node and one or more management nodes.
In this scenario, the existing vCenter Server and vCenter Single Sign-On certificates are retained and used as machine SSL certificates. VMCA assigns a VMCA-signed certificate to each solution user (collection of vCenter services). A solution user uses this certificate only to authenticate to vCenter Single Sign-On, so it might be unnecessary to replace solution user certificates.
You can no longer use the vSphere 5.5 certificate replacement tool, which was available for vSphere 5.5 installations, because the new architecture results in a different service distribution and placement. A new command-line utility, vSphere Certificate Manager, is available for most certificate management tasks.
vCenter Certificate Interfaces
- vSphere Certificate Manager utility
- Perform all common certificate replacement tasks from the command-line.
For ESXi, you perform certificate management from the vSphere Web Client. Certificates are provisioned by VMCA and are stored only locally on the ESXi host, not in vmdir or VECS. See Certificate Management for ESXi Hosts.
Supported vCenter Certificates
For vCenter Server, the Platform Services Controller, 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.