Replacing the Appliance Management Site Certificate for vRealize Automation



VMware vRealize vRealize Automation Certificates

Published on 5 November 2016 by Christopher Lewis. Words: 533. Reading Time: 3 mins.

The Series

  1. Configuring SSL certificates for vRA 7.x (inc vRO)
  2. Replacing the Appliance Management Site Certificate for vRealize Automation
  3. Replacing the Control Center Certificate on an embedded vRO instance
  4. Replacing the Package Signing Certificate in vRO 7

Replacing the Certificate

This is the second post in a series tackling the extra certificates you may want to replace once you have deployed vRealize Automation.

After a quick look around the VMware Documentation Center and I found the article for replacing the VAMI certificate ( https://vra.fqdn:5480 ). The VAMI certificate can be replaced using the same SAN certificate used for the vRA Virtual Appliance during the installation wizard, but it will need to be converted to Privacy Enhanced Mail (PEM) format to do so.

I wont cover that process here as i have already covered it in A Muggles Guide to creating a PEM encoded SSL Certificate using OpenSSL

The gist of the replacement, which is covered Replace the vRealize Automation Appliance Management Site Certificate , is to backup the original server.pem file, upload (via SSH) a new server.pem file and restart the VAMI service, which is all very simple.

My main concern around changing the VAMI certificate is that within a vRealize Automation 7.x deployment, the Management Agent that is deployed to each of the Windows based IaaS components uses the thumbprint of the certificate to enable trusted communications with the Virtual Appliance .

Previously, I had a bad experience when deploying the VA, upgrading the VAMI via SSH and then trying to run the deployment wizard as it seemed not to work and caused all sorts of Management Agent errors. Such as the one below, which at the time, I couldn’t find any reason for:

I now know that (more than likely) the SSL Thumbprint for the Management Agent differed (i.e. was still using the self-signed cert) from the Virtual Appliance (which had the Trusted Cert) for some reason. Maybe I was just impatient.

So, I know you’re dying to ask it… What happens those Management Agents that are currently talking to the vRA VA using the self-signed certificate? Well the after a quick chat with @GrantOrchard , the good news is that VMware thought about that and there is a process to follow to automatically or manually (if your a glutton for punishment) update those Management Agent SSL Thumbprints! See Update Management Agent Certificate Recognition

In a nutshell, I followed the Automatic process which basically tells you to update the VAMI certificate on the primary VA and then wait 15 minutes for the synchronisation interval to pass (where the new SSL Thumbprint gets sent to the Management Agents). Then you upgrade the VAMI on the secondary VA.

You can then verify that within the VMware.IaaS.Management.Agent.exe.Config file that different stages have completed as shown in the following examples:

Both VA’s using Self Signed Thumbprint

<endpoint address="https://vra-01.fqdn:5480/" thumbprint="E61FA5A82EE496E6E7F8374C8A6A69C9EE86B352" /> 
<endpoint address="https://vra-02.fqdn:5480/"
thumbprint="**E61FA5A82EE496E6E7F8374C8A6A69C9EE86B352**" />

VAMI updated on VRA-01, VRA-02 still using Self Signed Certificate

<endpoint address="https://vra-01.fqdn:5480/" thumbprint="**78E4BF7E19346AC64EBFB54C5761E6C3B4C92292**" />
<endpoint address="https://vra-02.fqdn:5480/"
thumbprint="**E61FA5A82EE496E6E7F8374C8A6A69C9EE86B352**" />

**Both VA’s using CA Signed Certification Thumbprint **

<endpoint address="https://vra-01.fqdn:5480/" thumbprint="**78E4BF7E19346AC64EBFB54C5761E6C3B4C92292**" />
<endpoint address="https://vra-02.fqdn:5480/"
thumbprint="78E4BF7E19346AC64EBFB54C5761E6C3B4C92292" />

If you follow the VMware articles its a quick win and easy fix! But isn’t it always?

Published on 5 November 2016 by Christopher Lewis. Words: 533. Reading Time: 3 mins.