VASA Provider 9.1 ESXi validation error

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?

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 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 reboot the ESXi host.

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

(For a similar issue, VMware indicates that you can restart the proxy service by running:  /etc/init.d/rhttpproxy restart  I don’t think I had any luck with that versus a reboot but it doesn’t hurt to try if you want to avoid the reboot.)

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. 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. Hopefully in the next VP release we will add that ignore button and the issue will be moot, regardless of the vSphere version.

10 thoughts on “VASA Provider 9.1 ESXi validation error

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.

Leave a Reply

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

WordPress.com Logo

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

Google photo

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

Twitter picture

You are commenting using your Twitter 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.

Powered by WordPress.com.

Up ↑

%d bloggers like this: