VASA Provider 9.1 ESXi validation errors

In our recent PowerMaxOS release I mentioned that we have a new VASA Provider, version 9.1. I noted our recommendation to upgrade to this release, particularly for the performance benefit related to snapshots; however, I failed to mention a VMware bug in ESXi 6.7 that can cause issues when deploying the new version. I was reminded of it yesterday while, oddly enough, helping a VMware team with registering the VP. So what’s the issue?

VMware Bug

In VP 9.1, we’ve added a new button to the GATEKEEPERS screen labeled, VALIDATE ESXI. After adding the ESXi host, you are required to select this button and accept the certificate from the ESXi host. Unfortunately, unlike when registering the VP in the vCenter, you can’t ignore the certificate and just accept it (a la browser). (I did ask for that capability when I tested this, but it never made it into the VP. I hope it will be in the future, but back to our current issue.)  So basically the validate must succeed. In the image below, after adding my ESXi host where the VP is currently running (step 1), I then hit the validate button (step 2), and receive the error (step 3) that the vApp cannot get the certificate.

Now as I wrote above, this issue (VMware KB 60216) only impacts vSphere 6.7 because VMware made a change to the /etc/vmware/rhttpproxy/config.xml file. Specifically they commented out the following line (77), which used to be un-commented before 6.7:

 <!-- <keyStoreFile>/etc/vmware/ssl/castore.pem</keyStoreFile> -->

Commenting out this line, causes the error on validation. The fix, therefore, is to un-comment the line and either run “/etc/init.d/rhttpproxy restart” or reboot the ESXi host. The former obviously is online, but I have seen where a reboot was needed so I include them both.


After the host comes back up, re-attempt validation and now you will get the certificate:

Select YES, and the certificate will be validated. At that point the ADD ARRAY button will un-gray and you can add the PowerMax.

When will the file be fixed? I don’t know to be honest. I’ve checked the two patch levels VMware says it is fixed in, U2 and U3, but it is still commented. In fact it is still broken in vSphere 7. Best recommendation I can provide is that as you can install the VP on any vCenter, if you have a 6.5 environment I would use that, otherwise the simple file change will take care of it, albeit with a host reboot or restart of rhttpproxy. Hopefully in the next VP release we will add that ignore button and the issue will be moot, regardless of the vSphere version.

Certificate Issue

I’m adding a second error which I’ve experienced with the validation of the ESXi. Once you fix the above bug, and receive the certificate information asking you to accept it, you still might receive a “The ESXi validation failed.” In my case, and this may be true for some of you also, I add my ESXi hosts to my vCenter by IP rather than FQDN. Doing so means that the above certificate will show the CN value to be an IP rather than the FQDN. In some of my testing, the VASA Provider vApp rejected the certificate because of this. To solve, I had to remove my ESXi host from my vCenter, add it back with the FQDN, then renew the certificates in vCenter. A new certificate is generated with the CN having the FQDN. Then the validation succeeds.



12 thoughts on “VASA Provider 9.1 ESXi validation errors

Add yours

  1. Thank you for this post! As of this date, this is the only place I have found that documents this behavior. I completed the steps and uncommented the line referenced within config.xml and then rebooted the ESXi host. Unfortunately, I’m still presented with the same error when trying to validate the ESXi host. I have tried removing and re-adding the ESXi Host within vApp Manager but still receive the same error. Any additional ideas or suggestions?

    1. Do you get the exact same error or does it provide a certificate and then fails to accept it? My experience with this is that either the file change and reboot fixes the issue completely, or it is a partial fix where you get to a second screen that provides the certificate, but then it fails to accept it (due to hostname/IP mismatch). Some general things to check are DNS is set for the vApp, and that your ESXi host and vApp resolve properly with DNS lookups. If all that comes back as valid, indicating the certificates should be OK, if you have a different ESXi host, I’d try that first, otherwise you’ll need to open an SR and provide vApp logs and development can review the specifics of your environment.

      1. @Drew – Thanks for the response! The error is exactly the same, “Failed to retrieve the issuer certificate”. Unfortunately it never provides the certificate details, it behaves exactly the same as before with just the error. I’ve double checked DNS and vApp is setup with DNS servers and resolving its name. Both vApp and the ESXi host are able to resolve and ping one another as well. I’ll attempt this procedure with another ESXi host and see if I get a different result.

      2. OK. If you have the same problem with the other host, then definitely proceed to open an SR, but be sure to note that you have already attempted the workaround. When I was only able to get it to partially work, I ended up having to modify some files and re-generate certificates to resolve. It took a bit of trial and error and I’m afraid I didn’t fully document it as VMware had said at the time they already resolved it (which appears to not have happened).

  2. I faced same issue at 2nd stage and found that hostname in ESXi is configured in caps and while registering ESXi in VASA provider we were using small letters. Correcting same resolved issue. Take SSH session of ESXI and run hostname command, copy output and paste while adding host in gatekeeper option

  3. Hi Drew,

    We are facing same issue on Solution enabler, even after following this article.
    Do you have any solution?

    1. This is the solution for this particular issue, so if you continue to have problems after following the steps, then you need to open an SR with support so they can review the logs and see what else might be causing the problem in your environment. There are other mis-configurations that can lead to failures. If necessary they can also get development involved to resolve. If you wanted to try something yourself before contacting support, given that you already had a host capitalization issue, I’d re-deploy the vApp and try again. If you already did that, then definitely time for support.

  4. Hi all, finally got time to re-focus on this problem. After spending some time looking a number of configurations, the hostname is case sensitive and its formatting is critical. (Padmakar and Drew both mentioned). I finally got mine to verify and thus allowed me to online the VASA provider.

    My ESXi servers, despite it showing up in vCenter and in the DICU, didn’t have the fqdn hostname defined.

    – hostname literally showed the hostname
    – esxcli system hostname get showed no domain name, and only the computer name for both hostname and fully qualified domain name.

    Here are the steps I used to resolve the issue:

    1. Placed the ESXi Host (6.7x) into maintenance mode AND disconnect host in VCenter (if applicable)

    2. Set Hostname with commands below, replace contents inside { } with your specifics.

    esxcli system hostname set –host={hostname}
    esxcli system hostname set –fqdn={hostname.domain}

    3. Restarted hostd and vpxa services (Management)
    /etc/init.d/hostd restart && /etc/init.d/vpxa restart

    4. Reconnected Host in vCenter and Exited Maintenance Mode

    5. Revalidated ESXi Host within Dell vApp Manager for PowerMax VASA Provider.

    Just to cover all basis, I have always formatted my SSL certs as outlined by VMWare. See these two pages. The first overall references OpenSSL Config file, but the common names and subject alternate names sections are important.

    Overall Process:

    OpenSSL Config File (exactly like this)

    I truly hope this helps resolve this for those of you still running into issues.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website Powered by

Up ↑

%d bloggers like this: