The VMware Certificate Authority (VMCA) provisions each new ESXi host with a signed certificate that has VMCA as the root certificate authority by default. Provisioning happens when the host is added to vCenter Server explicitly or as part of installation or upgrade to ESXi 6.0 or later.
You can view and manage ESXi certificates from the vSphere Client and by using the vim.CertificateManager API in the vSphere Web Services SDK. You cannot view or manage ESXi certificates by using certificate management CLIs that are available for managing vCenter Server certificates.
Certificates in vSphere 6.0 and Later
When ESXi and vCenter Server communicate, they use TLS for almost all management traffic.
|VMware Certificate Authority (default)||Use this mode if VMCA provisions all ESXi hosts, either as the top-level CA or as an intermediate CA.
By default, VMCA provisions ESXi hosts with certificates.
In this mode, you can refresh and renew certificates from the vSphere Client.
|Custom Certificate Authority||Use this mode if you want to use only custom certificates that are signed by a third-party or enterprise CA.
In this mode, you are responsible for managing the certificates. You cannot refresh and renew certificates from the vSphere Client.
Note: Unless you change the certificate mode to Custom Certificate Authority, VMCA might replace custom certificates, for example, when you select Renew in the vSphere Client.
|Thumbprint Mode||vSphere 5.5 used thumbprint mode, and this mode is still available as a fallback option for vSphere 6.x. In this mode, vCenter Server checks that the certificate is formatted correctly, but does not check the validity of the certificate. Even expired certificates are accepted.
Do not use this mode unless you encounter problems that you cannot resolve with one of the other two modes. Some vCenter 6.x and later services might not work correctly in thumbprint mode.
You can view information about certificate expiration for certificates that are signed by VMCA or a third-party CA in the vSphere Client. You can view the information for all hosts that are managed by a vCenter Server or for individual hosts. A yellow alarm is raised if the certificate is in the Expiring Shortly state (less than eight months). A red alarm is raised if the certificate is in the Expiration Imminent state (less than two months).
ESXi Provisioning and VMCA
When you boot an ESXi host from installation media, the host initially has an autogenerated certificate. When the host is added to the vCenter Server system, it is provisioned with a certificate that is signed by VMCA as the root CA.
The process is similar for hosts that are provisioned with Auto Deploy. However, because those hosts do not store any state, the signed certificate is stored by the Auto Deploy server in its local certificate store. The certificate is reused during subsequent boots of the ESXi hosts. An Auto Deploy server is part of any embedded deployment or vCenter Server system.
If VMCA is not available when an Auto Deploy host boots the first time, the host first attempts to connect. If the host cannot connect, it cycles through shutdown and reboot until VMCA becomes available and the host can be provisioned with a signed certificate.
Required Privileges for ESXi Certificate Management
For certificate management for ESXi hosts, you must have the privilege. You can set that privilege from the vSphere Client.
Host Name and IP Address Changes
A host name or IP address change might affect whether vCenter Server considers a host certificate valid. How you added the host to vCenter Server affects whether manual intervention is necessary. Manual intervention means that you either reconnect the host, or you remove the host from vCenter Server and add it back.
|Host added to vCenter Server using...||Host name changes||IP address changes|
|Host name||vCenter Server connectivity problem. Manual intervention required.||No intervention required.|
|IP address||No intervention required.||vCenter Server connectivity problem. Manual intervention required.|