Security policy asks for every ESXi host to carry a certificate from the company's own certificate authority. The new certificate goes on, and the host drops to Disconnected in vCenter. Reconnect fails.
Broadcom has two knowledge base articles for this, and they end in different places. KB 417709 leaves vCenter in thumbprint mode. KB 426137 passes through thumbprint mode and returns to custom mode before a corrected certificate request, because the mode "must be set to custom before you can use the vSphere Client to generate a CSR for an External CA". Each describes one case; neither is a general repair, and this article reproduces neither. The vSphere 8.0 guide says "Use legacy thumbprint mode for debugging." and that thumbprint mode does not check certificate validity. Any mode choice is a security decision. This article records the facts that decision needs, then hands it over.
Scope
vCenter Server 8.0 with ESXi 8.0 hosts. Reads only, in the vSphere Client and on the certificate files you were given. Not covered: vCenter's own certificate (see the published article on vCenter sign-in failing after a certificate expires), hosts that are not responding for other reasons (see ESXi host not responding or disconnected), Auto Deploy and vSAN-specific steps.
The certificate modes in vSphere 8.0
vCenter decides how it treats host certificates with the advanced setting vpxd.certmgmt.mode. The 8.0 guide lists three values: "The available options are vmca , custom , and thumbprint ."
- vmca (default). vCenter's own certificate authority issues host certificates. The guide warns: "Unless you change the certificate mode to Custom Certificate Authority ( custom ), VMCA might replace custom certificates, for example, when you select Renew in the vSphere Client ." VMCA can also sit under your enterprise CA: "VMCA is the root CA by default, but it can be set up as the intermediary CA to another CA." The guide says vmca mode is "Also used if VMCA is a subordinate certificate." A host certificate whose chain reaches your enterprise root may therefore still have been issued by VMCA.
- custom. "In custom mode, you are responsible for managing the certificates."
- thumbprint. "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."
The guide also says that before you replace a host certificate, "you must update the TRUSTED_ROOTS store in VECS on the vCenter Server system that manages the host to ensure that the vCenter Server and the ESXi host have a trust relationship."
The two published error patterns
| KB (versions stated) | Reconnect error | Cause the KB gives |
|---|---|---|
| 417709 (vCenter and ESXi 7.0.x, 8.0.x) | "Authenticity of the host's SSL certificate is not verified." | "The vpxd.certmgmt.mode parameter was set to vmca", while the hosts used a custom CA-signed certificate |
| 426137 (7.x, 8.x) | "Unable to get signed certificate for host |
A mismatch between the certificate's Common Name and the host FQDN as vCenter recognises it, with the mode set to custom; the KB says it typically occurs where hosts were added by IP address, or where the mode is custom and the certificate is issued to the host FQDN |
KB 426137 adds that vCenter's service "may fail to recognize management mode changes until the service is manually restarted." Record whether the mode was changed, and whether vCenter has restarted since then (field D).
Step 1: record the event
| Field | What to record |
|---|---|
| A | vCenter version and build; each affected host's ESXi version and build |
| B | Which hosts got new certificates, when (with time zone), by whom, and how: vSphere Client, ESXi Shell, or another tool |
| C | The exact reconnect error text from the task, with time |
Step 2: record vCenter's side
| Field | What to record |
|---|---|
| D | vpxd.certmgmt.mode value (vCenter > Configure > Advanced Settings, filter vpxd.certmgmt); whether and when it was changed; when vCenter's services last restarted, if known |
| E | Which roots and intermediates are in vCenter's trusted roots, where that statement comes from (owner report or a dated store listing already on file) and when each was added |
| F | The exact name each host has in the inventory (FQDN or IP address), and the host's machine FQDN |
Step 3: record the host certificate
For every certificate fact, record its source and time. The host's single-host certificate view in the vSphere Client shows Subject, Issuer, Valid From, Valid To and Status; "The following information is available only in the single-host view." It does not show every Subject Alternative Name or the chain, so those come from a certificate file. A file counts as evidence for this incident only when the certificate owner confirms it is the certificate installed on that host, for example by a matching serial number or fingerprint recorded with a date. Never record or copy a private key. Without that confirmation, mark the field unknown. The 8.0 guide also notes that certificate details cannot be viewed for hosts in thumbprint mode.
The 8.0 guide requires "CN (and SubjectAltName) set to the host name (or IP address) that the ESXi host has in the vCenter Server inventory." and "SubjectAltName must contain DNS Name=
| Field | What to record |
|---|---|
| G | Common Name and each Subject Alternative Name entry (DNS and IP), with source and time |
| H | The immediate issuer of the host certificate; the chain to the root, if available; and the VMCA topology as the vCenter owner confirms it: VMCA as root, VMCA subordinate to your enterprise CA, or host certificates issued directly by your enterprise CA |
| I | Valid From and Valid To, with source and time |
| J | Two checks, each yes, no or unknown: (1) do the CN and a SAN carry the exact inventory name or IP address in F; (2) does a SAN carry the machine FQDN as a DNS name |
Step 4: classify
| What the record shows | Candidate explanation | Handed to |
|---|---|---|
| D is vmca, C matches KB 417709, and H confirms the host certificate was issued directly by your enterprise CA, not by VMCA | Mode and certificate disagree (KB 417709 pattern) | Certificate owner and vCenter owner |
| H shows the host certificate was issued by VMCA acting as a subordinate of your enterprise CA | Not a mode disagreement on that basis; vmca mode is documented for this case | vCenter owner |
| D is custom, C matches KB 426137, and J(1) is no | Name mismatch (KB 426137 pattern) | Certificate owner |
| J(1) or J(2) is no, but C or D does not match KB 426137 | Name requirement not met; not the KB 426137 pattern | Certificate owner |
| D was changed, and vCenter has not restarted since | The mode change may not have taken effect | vCenter owner |
| Dated evidence in E and H shows a root or intermediate of the host certificate's actual chain missing from vCenter's trusted roots | Trust relationship candidate | Certificate owner |
| I shows not yet valid or expired, and D was vmca or custom at the time of C | Validity candidate. In thumbprint mode expiry alone does not explain a rejection: "Even expired certificates are accepted." | Certificate owner |
| Evidence missing or unconfirmed, C matches neither KB, or fields conflict | Unresolved | vCenter owner, record as is |
More than one row can apply at once.
What this record does not authorise
This record does not authorise changing vpxd.certmgmt.mode, restarting vCenter services, removing or re-adding hosts, replacing certificate files, rebooting hosts or adding trusted roots. Each of those is a change. Thumbprint mode in particular turns off certificate validity checks; the 8.0 guide also says "Some vCenter Server 6.x and later services might not work correctly in thumbprint mode."
The certificate owner and vCenter owner decide, with at least:
- which mode the organisation's policy requires, and whether thumbprint is acceptable even briefly;
- whether a corrected certificate (name, chain) is the better fix than a mode change;
- the effect on HA, backup, monitoring and anything else that talks to the host;
- who checks the result.
A mode change is not a setting that can simply be switched back. The 8.0 workflows for moving to vmca mode start by removing the hosts from vCenter, and warn: "Any other workflow for this mode switch might result in unpredictable behavior." Any future change therefore needs its own written plan for the exact versions and topology, the list of affected hosts and integrations, and a checked way to stop or recover. That plan is reviewed separately and approved on its own; this record is not that plan.
Worked example (fictional)
The values below are invented. vCenter vc-01 8.0 U3 manages esx-21 and esx-22 (ESXi 8.0 U3). On 4 November at 10:10 AEDT the platform team installs certificates from the company CA on both hosts through the ESXi Shell. Both go to Disconnected.
| Field | esx-21 | esx-22 |
|---|---|---|
| C | "Authenticity of the host's SSL certificate is not verified." | same |
| D | vmca; never changed; read 10:30 | same |
| E | Company root and issuing CA in trusted roots since 3 November (dated store listing on file) | same |
| F | esx-21.corp.example |
10.20.0.22; machine FQDN esx-22.corp.example |
| G | CN and DNS SAN esx-21.corp.example; file confirmed by serial number, owner, 10:40 |
CN and DNS SAN esx-22.corp.example; no IP SAN; same source |
| H | Issued by Corp Issuing CA 2; vCenter owner confirms VMCA is the root CA, not subordinate | same |
| I | Valid from 3 November | same |
| J | (1) yes; (2) yes | (1) no: neither CN nor SAN carries 10.20.0.22; (2) yes |
Classification: both hosts match the KB 417709 row: vmca mode, a certificate issued directly by the enterprise CA, and that KB's error text. esx-22 also fails name check (1). Its mode and error do not match KB 426137, so that is recorded as a separate unmet requirement, not as that KB's pattern. This record does not show which issue, alone or together, stops each host reconnecting. It goes to the certificate owner and vCenter owner. No setting is changed.
Acceptance checks
- Fields A to J are recorded for each affected host, or marked not available with the reason.
- The exact error text is recorded per host.
- Each certificate field names its source and time; a file not confirmed as the installed certificate leaves the field unknown.
- J is recorded as two checks against the named entries (CN, each SAN, inventory name, machine FQDN), not as one whole-string comparison.
- Each host ends in a candidate row or as unresolved, with the owner named.
- No setting, service, certificate or inventory entry was changed.
Learning notes
- In vmca mode, vCenter expects VMCA to issue host certificates, including when VMCA is subordinate to an enterprise CA.
- A custom certificate needs its chain trusted by vCenter before it goes on the host.
- The CN and a SAN must carry the name or IP address vCenter uses for the host, and a SAN must carry the machine FQDN.
- Thumbprint mode stops vCenter checking certificate validity; choosing it is a security decision.
Related articles
- Published: vCenter Sign-In Fails After a Certificate Expires: Find the Store Responsible
- Published: ESXi Host Not Responding or Disconnected in vCenter: Narrow the Cause
Sources
KBs retrieved 2026-11-03 between 18:33:28 and 18:33:29 UTC, TechDocs pages between 18:34:07 and 18:34:23 UTC (early on 4 November, Australia/Sydney). Dates are each page's own Last Updated or Updated On date.
- Broadcom TechDocs, vSphere 8.0, "Managing Certificates for ESXi Hosts", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-esxi-hosts/certificate-management-for-esxi-hosts.html
- Broadcom TechDocs, vSphere 8.0, "ESXi Certificate Mode Switch Workflows", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-esxi-hosts/certificate-management-for-esxi-hosts/certificate-mode-switches.html
- Broadcom TechDocs, vSphere 8.0, "Change the ESXi Certificate Mode", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-esxi-hosts/certificate-management-for-esxi-hosts/change-the-certificate-mode.html
- Broadcom TechDocs, vSphere 8.0, "Replacing the Default ESXi Certificate with a Custom Certificate", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-esxi-hosts/certificate-management-for-esxi-hosts/replacing-esxi-certificatea-intro.html
- Broadcom TechDocs, vSphere 8.0, "View Certificate Expiration Information for ESXi Hosts", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-esxi-hosts/certificate-management-for-esxi-hosts/view-certificate-information-for-multiple-esxi-hosts.html
- Broadcom KB 417709, "ESXi hosts got disconnected from vSphere after replacing the default certificates with custom certificates on the hosts.", 10 November 2025. https://knowledge.broadcom.com/external/article/417709/esxi-hosts-got-disconnected-from-vsphere.html
- Broadcom KB 426137, "ESXi Host Disconnection From vCenter After SSL Certificate Replacement", 21 January 2026. https://knowledge.broadcom.com/external/article/426137/esxi-host-disconnection-from-vcenter-aft.html