vsphere 6.7 U3a – VSAN / HTML5- Failed to extract requested data

My VSAN lab has been experiencing this issue since updating to 6.7 U3 + U3a.


The documented fix being U3a, but issue is still present in my environment.

Another user mentioned that he experienced an issue with services IDs having bad/old thumbprint. With the script ls_ssltrust_fixer.py he was able to resolve this glitch.

I believe I maybe experiencing this same issue as my vsphere_client_virgo.log reads:

com.vmware.vsphere.client.vsan.base.cache.TimeBasedCacheEntry Unable to get the validation token – invalidating the value com.vmware.vsphere.client.vsandp.core.sessionmanager.common.NotAccessibleException: Cannot connect to the specified site.

Caused by: com.vmware.vim.vmomi.client.exception.SslException: com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate chain is not trusted and thumbprint doesn’t match

I’ve tried regenerating the VCSA Sub CA cert w/ my internal Microsoft AD CA and replacing all. Didn’t help.

Searching around I cannot find any info about this script or possible resolution to get my HTML5 VSAN management working again. My 2 node robo environment was without any issue prior to U3.

Any help to share script or provide feedback on issue would be appreciated. Thank you.

View Reddit by iL1feView Source

Related Articles

One Comment

  1. Once the SSL trust anchors are mismatched, not amount of regenerating or replacing the Machine SSL certificate is going to fix it, it requires manual correction.

    I have a script that I’ve used countless times to troubleshoot and correct this issue:


    I recommend running it first with the following options:

    `./check-trust-anchors -cml`

    This will:

    1. colorize the output for quick identification of the pertinent pieces of information
    2. print the current Machine SSL certificates for all PSC/vCenters for comparison (assuming they’re reachable on the network)
    3. denote that it is being run on a live system (as opposed to a support bundle), and will automatically dump the Lookup Service registrations

    The script will print the unique SSL certificates being used as SSL trust anchors within the Lookup Service registrations. Each vCenter/PSC node should have certain services registered with the Lookup Service, and as such each node should have its current Machine SSL certificate listed (there are other solutions that would have one, Site Recovery Manager for instance). You can list the URIs that are using each unique certificate by including the **-e** option.

    If you verify that your current Machine SSL certificate does not match the SSL certificate that the service registrations are using for the URIs that are pointed to that node, you can try and have the script fix them by including the **-f** option. This will list the unique certificates and then prompt you for four things:

    1. The SSO administrator account (defaults to “administrator@<your-sso-domain>”, you can just hit Enter to accept the default)
    2. The SSO administrator password
    3. The SHA1 thumbprint of the certificate you want to **replace** (this should be one of the Endpoint certificates, not your current Machine SSL certificate)
    4. The FQDN/IP of the node you want to replace. The script needs to be run on one of the PSCs in the SSO domain. If your PSC is embedded, you can run it from the vCenter. If you are running it from the node you want to update the SSL trust anchors for, you can simply type “localhost”

    The script uses the included `/usr/lib/vmidentity/tools/scripts/ls_update_certs.py` Python utility, which in turn uses the included Lookup Service libraries. You should see output similar to when you replace the Machine SSL certificate using the `/usr/lib/vmware-vmca/bin/certificate-manager` utility: at the end it should tell you how many services it updated (and it needs to be more than zero). If you do not receive a message stating how many services it updated, that means it hit a service registration it couldn’t parse (as is a common problem with this utility), and you should run the check-trust-anchors script again to see if there are still any outstanding service registrations that are still using the wrong SSL certificate.

    Usual caveats apply: take offline snapshots of **all** PSCs in the SSO domain before attempting to fix anything.

    Edit: I just read the KB you linked, was your environment upgraded from 5.5? If so, there’s some additional things you need to check (legacy SSO endpoints and a separate store in VECS).

Leave a Reply