Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

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

A general system error occurred: Unable to push CA certificates and CRLs to host, Adding or Reconnecting 6.7 ESXi host to vCenter Server fails (74756)

Last Updated: 4/8/2024Categories: TroubleshootingTotal Views: 148658Language:
Chinese (Simplified)English

81 like this article

Subscribe to get an email
newsletter with new updates

81 people found this helpful Please provide article feedback:

Learn how VMware Skyline Advisor and Skyline Health Diagnostics work together to provide proactive intelligence and self-service log analysis.

Use Skyline Advisor to avoid issues before they occur across VCF, vSphere, vSAN, NSX, vROps & Horizon. Skyline Findings are based on top KBs, VMSAs/CVEs and design best practices.

Use Skyline Health Diagnostics to root cause vSphere & vSAN logs when an issue occurs. Skyline Health Diagnostic Findings are based on top KBs and VMSA/CVEs. You can use the Skyline Health Diagnostics tool in online or offline mode.

If you require additional help from technical support, please use Skyline Advisor to initiate a Log Assist to reduce time to upload logs. TSEs can also initiate logs to reduce effort.

Symptoms

Adding or Reconnecting ESXi 6.7 host fails with below error message

"A general system error occurred: Unable to push CA certificates and CRLs to host"

Same error is observed during Renewing the certificate of ESXi host from vCenter Server using WebClient or UI Client

In /var/run/log/hostd.log file on the ESXi host, you see entries similar to :

2019-09-12T11:39:17.594Z error hostd[2099958] [Originator@6876 sub=Vimsvc.CertMgr opID=22aa0399-86e0-4120-a9c5-43173a148302-122905-auto-122907-h5
c:70009449-db-6fa0 user=vpxuser:VSPHERE.LOCAL\administrador] Certificate is not a valid CA certificate: -----BEGIN CERTIFICATE-----
<certificate string>
--> -----END CERTIFICATE-----

Cause

This issue is due to self-signed or Non-CA certificates in TRUSTED_ROOTS store on the vCenter Server getting pushed to ESXi host while adding/reconnecting or while renewing the Certificate on the host.

Impact / Risks

This change allows for self-signed certificate to added to the ESXi

Resolution

Note: This issue can also happen due to time sync issues, if the ESXi host time is incorrect when compared to vCenter Server. Please verify the time on ESXi and vCenter Server before proceeding with below steps.

To resolve the issue perform one of below Options :

Option 1:
Remove Non-CA or Self-Signed certificates from TRUSTED_ROOTS store of vCenter Server by following below steps.

Caution: In environment with VASA provider (eg - VVOL) configuration, it is observed that VASA provider self-signed certificates are getting added to TRUSTED_ROOTS store and removing these certificates from TRUSTED_ROOTS will result in VASA provider becoming Offline. If you have such configuration :

Proceed with Option 2 if ESXi Host build is 6.7 Update 3 or later

Contact VASA provider vendor to configure signed certificate before proceeding to Option 1

Execute below command to list Key Usage and Alias field of each certificate in TRUSTED_ROOTS store

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|Key Usage' -A 1 | grep -v "Entry type"

Identify the Certificate Aliases which does not have 'Certificate Signing' keyword under Key Usage parameter, these are Non-CA certificates

In below example, Alias 5deae7b5e95deddad3d4c38447210ffe23119d6d does not have Certificate Signing which means it is not a CA Certificate

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|Key Usage' -A 1 | grep -v "Entry type"
Alias : e74a421e72fa9c2c6a44312962be982ba1c251bf
--
X509v3 Key Usage: critical
Certificate Sign, CRL Sign

Alias : 5deae7b5e95deddad3d4c38447210ffe23119d6d
--
X509v3 Key Usage:
Digital Signature, Key Encipherment, Key Agreement

Take backup of Non-CA certificates identified from above steps by executing below command. This step and following steps needs to be performed for each certificate identified from above step.

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store TRUSTED_ROOTS --alias <alias name> --output /var/tmp/<aliasname.crt>

Example:

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store TRUSTED_ROOTS --alias 5deae7b5e95deddad3d4c38447210ffe23119d6d --output /var/tmp/5deae7b5e95deddad3d4c38447210ffe23119d6d.crt

Un-publish the certificate from VMware Directory Service by executing below command, it will ask for SSO Administrator password

/usr/lib/vmware-vmafd/bin/dir-cli trustedcert unpublish --cert <certificate full path> --login administrator

Note: If it is not published, you will observe error "dir-cli failed. Error 1168: Operation failed with error ERROR_NOT_FOUND (1168)". Please ignore this message and proceed with next step to remove the certificate from the store.

Example:
/usr/lib/vmware-vmafd/bin/dir-cli trustedcert unpublish --cert /var/tmp/5deae7b5e95deddad3d4c38447210ffe23119d6d.crt --login administrator

dir-cli unpublish command should automatically delete the certificate from TRUSTED_ROOTS store if it is published. If not, execute below command to remove the certificate from VECS store

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <alias name> -y

Example:
/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias 5deae7b5e95deddad3d4c38447210ffe23119d6d -y

Retry adding the ESXi host to vCenter Server or certificate renew operation

Option 2:
Modify the advanced configuration "Config.HostAgent.ssl.keyStore.allowSelfSigned" introduced in ESXi 6.7 Update 3 to ignore the Self Signed Certificates.

Connect to the ESXi using Host Client

Select Manage Tab

Select Advanced Settings

Locate the option "Config.HostAgent.ssl.keyStore.allowSelfSigned"

Edit the value from false to true

Reboot the ESXi host.

Retry adding the ESXi host to vCenter Server or certificate renew operation

Related Information

VMware Skyline Health Diagnostics for vSphere - FAQ
Please note that advanced setting "Config.HostAgent.ssl.keyStore.allowSelfSigned" is only available in ESXI 6.7 U3 and above, therefore it is a requirement to be at this release.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)English

Attachments

Additional Resources

KB
•
应用热修补程序后，Usage Meter 无法导出日志包并发送未加密的报告 (74693)

KB
•
ホット パッチを適用した後、使用量メーターがログ バンドルのエクスポートに失敗し、暗号化されていないレポートを送信する (74693)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere ESXi

Related Versions:

VMware vSphere ESXi 6.7

Take Our Survey

Support Assistant