vRA 8.8.2 “Failed to validate” error after vCenter certificate change

by ·

When a vCenter certificate expired after you have renewed it you need to add this new certificate to the solutions that are linked with the vCenter. Generally it is enough to just re-authenticate with the service user because the vCenter provide the new certificate that can be accepted. But there is a bug in the vRealize Automation and because of this this is not this straightforward. Writing this because the vRA faced with “Failed to validate” issue.

Solution

At the time of troubleshooting and the writing of this article there is no patch provided by VMware so the following steps should be implemented to fix the issue.

Obtain Bearer token

Access vRA – cloud Assembly then go to Infrastructure > Connections > Cloud Account page. Here open the browser’s Developer Tools then select Network. If it is required then click to Refresh and find access then Authorization on the right. If possible use Raw option because for example the Firefox can use different character set that can cause authentication issues later on.

Obtain vCenter Cloud Account ID

The easiest way to get this ID is from the UI by opening the respective vCenter within the Cloud Accounts page:

The alternative way is using Postman. The Postman will be required later on so I recommend you to use this method instead the previous one. For this start the Postman and set as follows:

  • Authorization: Select Bearer Token and paste the previously obtained token
  • Headers: add “api_version” Key with “2021-07-15” Value

Then select GET option and enter https://vRA-FQDN/iaas/api/cloud-accounts/ where the vRA-FQDN is your vRA solution’s VIP or Node IP address. If everything goes well you get “Status: 200 OK” and the details of the configured Cloud Account. If you navigate to the vCenter that is afeected you will find the cloudAccountId. This and the previous one should be the same:

Capture the vCenter’s certificate in PEM format

To do this login to the vRA Node with root account and issue the following command, just replace the vCenter_FQDN:

openssl s_client -connect vCenter_FQDN:443 2> /dev/null | openssl x509 | awk 'NF {sub(/\r/, "");  printf "%s\\n",$0;}'

Save the full output, including the “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” part as well.

Using Postman to fix the issue

Verify that you have all the necessary information:

  • Bearer toke – if it took a long time to get here repeat the steps mentioned above and obtain the token again, maybe it has been expired because timeout
  • vCenter Cloud Account ID
  • vCenter certification in PEM format
  • IP or FQDN of the vCenter – as it is configured in the Cloud Accounts page

Now it is time to create the body for the PATCH call. To do this do not use Notepad but Notepad++, PSPad or Visual Studio Code:

{
        "customProperties" : {
            "certificate": "PEM certificate"
        },
        "endpointProperties": {
        "hostName": "vCenter IP or FQDN",
        "certificate": "PEM certificate"
    }
}

Open the Postman and enter https://vRA-FQDN/provisioning/uerp/resources/endpoints/Cloud Account ID to the URL field but change the vRA-FQDN and Cloud Account ID and also verify/change the Bearer Token. Furthermore verify on the Headers page that the “api_version” key’s value is 2021-01-15 and the “Content-Type” is set to application/json. If any of these values are different fix or add them before continue:

Click to the Send button and after the successful execution the Postman return “Status: 200 OK” message:

When you go back to “Cloud Accounts” in the vRA the error message cannot be displayed and you will be able to insert the vCenter service user’s credentials and after you click to Validate , the Save button become active, you can save the configuration and the synchronization is starting.

Tags: