Loading

×Sorry to interrupt
This page has an error. You might just need to refresh it.
[NoErrorObjectAvailable] Uncaught ReferenceError: addCTracking is not defined
Failing descriptor: {markup://c:KM_ArticleThemeLayout}

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

vCenter Server, ESXi and/or NSX are disconnected after a Cloud Director 10.1, 10.3 or 10.4 upgrade (78885)

Last Updated: 7/21/2022Categories: TroubleshootingTotal Views: 33047Language:
Chinese (Simplified)JapaneseFrenchSpanishEnglishGerman

12 like this article

Subscribe to get an email
newsletter with new updates

12 people found this helpful Please provide article feedback:

Symptoms

After upgrading to VMware Cloud Director (VCD) 10.1, 10.3, 10.4, vCenter Server and/or NSX-V / NSX-T servers are disconnected.

After upgrading to VMware Cloud Director (VCD) 10.4, you are presented with the following banner

VMware Cloud Director 10.4 and later versions use the latest SSL practices for integration with the vSphere infrastructure. You must verify that VMware Cloud Director trusts all necessary vSphere certificates. See KB 78885

After upgrading to VMware Cloud Director (VCD) 10.4, tasks which require direct ESXi connections such as Consoles, Guest Customization or OVF/Media Uploads will fail

Within log reviews, the provider might see the following errors :

Error: Unable to find valid certification path to requested target

Error: Certificate for <X.Y.Z> doesn't match any of the subject alternative names: [A.B.C]

Error: IOException while reading data. Closing transfer ... Received fatal alert: bad_certificate

Cause

VMware Cloud Director introduces enhanced SSL validation which prohibits the option to trust all VC/NSX certificates without validation. If this configuration was previously used with self signed certificates that were not uploaded to VMware Cloud Director, this would result in the connection not being trusted by VCD upon upgrade.

VMware Cloud Director 10.4 extends the above requirements to ESXi and requires that the VMCA certificate is imported into the Cloud Director Truststore.

As of VMware Cloud Director 10.4, Hostname Verification is enabled by default.

VCD has removed a security hole that allowed cells to run without certificate verification.

Resolution

Note:

In VMware Cloud Director 10.4, Hostname Verification is enabled by default and must remain enabled.

The option to disable Hostname Verification is deprecated and will be removed in a future release of Cloud Director.

Hostname Verification can be validated via the UI or API

For the UI

Login to the Provider portal

Click Administration

Click General (within the Settings subsection)

Navigate to the Certificates section

Ensure Use hostname verification for vCenter Server and vSphere Certificates is enabled

For the API

Using a REST Client, update the General Settings of Cloud Director.

Ensure the VerifyVcCertificates element is set to true.

For SSL related errors, below are the options to resolve those issues:

Note:

For vCenter Server 7.x, all Options below are valid.

For vCenter Server 6.7.x, only Options 2 and 3 below are valid.

Option 1: Individually
Using the UI, edit each individual connection and click Save.
The UI will allow you to interactively review and trust individual certificates presented by each respective server (Trust-on-first-use principle).
In 10.4, post trusting the vCenter Server certificate, another prompt will appear for the VMCA certificate which is required for Cloud Director to trust the connections to ESXi Hosts.

Option 2: Automated
Run this cell-management-tool command to retrieve and trust certificates from all configured vCenter Server and NSX servers as well as the VMCA certificate (10.4):
/opt/vmware/vcloud-director/bin/cell-management-tool trust-infra-certs --vsphere --unattended
This command helps by providing additional options on how to review the certificates that will be trusted before trusting them.

Option 3: Manual
Should the above options not be possible, the VMCA certificate can be downloaded manually and uploaded to the Cloud Director Truststore.

To manually download the vCenter Server Root Certificates please refer to the following KB .

To import the VMCA certificate follow the Cloud Director Import Trusted Certificates documentation.

For SAN related errors, below are the options to resolve the issue:

Option 1: For 10.3
The Provider must replace any certificate for VC, NSX-V or NSX-T managers to have valid SANs that match the hostname.

Related Information

07/19/2021 - Published externally

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseFrenchSpanishEnglishGerman

Attachments

Additional Resources

KB
•
How to download and install vCenter Server root certificates to avoid Web Browser certificate warnings (2108294)

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
vRealize Automation 8.0.1 的累积更新 (76805)

Results 1-3 of 3

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere

VMware NSX Data Center for vSphere

VMware Cloud Director

Related Versions:

VMware NSX-T Data Center

VMware Cloud Director 10.x

Take Our Survey

Support Assistant