6.0.3

Certificate Management Overview
The impact of the new certicate 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 certicates, VMCA can handle all
certicate management for you. VMCA provisions vCenter Server components and ESXi hosts with
certicates that use VMCA as the root certicate authority. If you are upgrading to vSphere 6 from an earlier
version of vSphere, all self-signed certicates are replaced with certicates 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 certicates that are
signed by a third-party or enterprise certicate authority or requires custom certicate information.
n
Replace the VMCA root certicate with a CA-signed certicate. In this scenario, the VMCA certicate is
an intermediate certicate of this third-party CA. VMCA provisions vCenter Server components and
ESXi hosts with certicates that include the full certicate chain.
n
If company policy does not allow intermediate certicates in the chain, you have to explicitly replace
certicates. You can use the vSphere Certicate Manager utility or perform manual certicate
replacement using the certicate management CLIs.
When upgrading an environment that uses custom certicates, you can retain some of the certicates.
n
ESXi hosts keep their custom certicates during upgrade. Make sure that the vCenter Server upgrade
process adds all the relevant root certicate to the TRUSTED_ROOTS store in VECS on the
vCenter Server.
After the vCenter Server upgrade, administrators can set the certicate mode to Custom (see “Change
the Certicate Mode,” on page 167). If certicate mode is VMCA, the default, and the user performs a
certicate refresh from the vSphere Web Client, the VMCA-signed certicates replace the custom
certicates.
n
For vCenter Server components, what happens depends on the existing environment.
n
If you upgrade a simple installation to an embedded deployment, vCenter Server custom
certicates are retained. After the upgrade, your environment will work as before.
n
If you upgrade a multi-site deployment where vCenter Single Sign-On is on a dierent 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 certicates are retained
and used as machine SSL certicates. VMCA assigns a VMCA-signed certicate to each solution
user (collection of vCenter services). A solution user uses this certicate only to authenticate to
vCenter Single Sign-On, so it might be unnecessary to replace solution user certicates.
You can no longer use the vSphere 5.5 certicate replacement tool, which was available for vSphere 5.5
installations, because the new architecture results in a dierent service distribution and placement. A
new command-line utility, vSphere Certicate Manager, is available for most certicate management
tasks.
vSphere Security
66 VMware, Inc.