Product Announcements

resxtop fails to connect to a vSphere 5.1 host

If you have recently installed the latest vCLI 5.1 release and using the remote resxtop utility to connect to a vSphere 5.1 host, you might have noticed one of the following error messages: Login failed, reason: HTTPS_CA_FILE or HTTPS_CA_DIR not set or SSL Exception: Verification parameters

The reason are you seeing this message is because the resxtop command has now been updated to support SSL Certificate validation in the vCLI 5.1 release. In previous releases, only the vSphere SDK for Perl supported SSL Certificate validation. This feature was optional and could be enabled on the client side to properly validate SSL Certificates for additional security on a vSphere host or vCenter Server prior to establishing a connection for communication.

Here is an example of how you would run resxtop with the CA cert located on the client system in /home/vi-admin/cacert.pem

You first need to set BOTH environment variables which specify the location of the CA certificate as well as the directory (similar to those defined by Crypt::SSLeay Perl module):

export HTTPS_CA_FILE=/home/vi-admin/cacert.pem

export HTTPS_CA_DIR=/home/vi-admin

Now, you can connect to your vSphere host as you would normally with resxtop:

resxtop –server esxi-1 –username root

In the process of encouraging customers to run vSphere more securely, we made an error by not accounting for scenarios where self-signed certificates were being used. A bug was introduced in resxtop which made the SSL Certificate validation code mandatory, instead of optional. This meant that users who wanted to use resxtop to connect to either their vSphere 5.1 host or vCenter Server, had to have valid SSL Certificates on the host. For customers who are currently replacing VMware’s self-signed SSL Certificates with proper signed CA Certificates, this was not a problem. The issue arises when trying to connect to a vSphere 5.1 host which uses self-signed SSL certificates and resxtop would reject the connection due to invalid certificates.

VMware is aware of the issue but was not able to fix it prior to vSphere 5.1 release. This known issue has also been documented in the vCLI 5.1 release notes:

resxtop fails to run agains vSphere targets

  • When you run resxtop against a vSphere 5.1 target, an error results.
    • If the SSL certificate is set in the vCLI client, the following error results:
    • SSL Exception: Verification parameters
    • If the SSL certificate is not set, the following error results:
    • Login failed, reason: HTTPS_CA_FILE or HTTPS_CA_DIR not set

Workaround: If your environment supports this, run esxtop in the ESXi Shell. Otherwise, no workaround.


We understand that this is quite frustrating for our customers trying to use resxtop in a vSphere 5.1 environment and rest assure, this is currently being worked on and we hope to have a solution very soon.

In the mean time, you do have a few options:

  1. Login to ESXi Shell an use the local esxtop command during a troubleshooting session. This is not ideal if you do not have SSH enabled but will allow you to quickly view esxtop data.
  2. You can use the vCLI 5.0 resxtop which does not have the SSL Certificate validation check. The only caveat is that you will not see some of the new esxtop performance counters.
  3. Replace VMware’s self-signed SSL Certificate with CA signed certificate. You can find more details in this VMware KB article. If you are running vCenter Server, then you can just replace the SSL Certificate on the vCenter Server and proxy your resxtop command through vCenter Server else you will need to replace the SSL Certificate on the vSphere 5.1 host.

Having said all this, I also did some investigation on the process of generating proper self-signed CA SSL Certificates and replacing them on a vSphere 5.1 host. In a follow-up post, I will share with you a script that you can use to generate and update your hosts with proper SSL Certificates so you can proceed with using resxtop until a fix is released.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw

Related Articles