A system administrator can update or replace certificates for vRealize Automation components.

vRealize Automation contains three main components that use SSL certificates in order to facilitate secure communication with each other. These components are as follows:

  • vRealize Automation appliance

  • IaaS website component

  • IaaS manager service component

In addition, your deployment can have certificates for the vRealize Automation appliance management site. Also, each IaaS machine runs a Management Agent that uses a certificate.


vRealize Automation uses several third party products, such as Rabbit MQ, to support a variety of functionality. Some of these products use their own self signed certificates that persist even if you replace primary vRealize Automation certificates with certificates supplied by a CA. Because of this situation, users cannot effectively control certificate use on specific ports, such as 5671 which is used by RabbitMQ for internal communication.

With one exception, changes to later components in this list do not affect earlier ones. The exception is that an updated certificate for IaaS components must be registered with vRealize Automation appliance.

Typically, self-signed certificates are generated and applied to these components during product installation. You might need to replace a certificate to switch from self-signed certificates to certificates provided by a certificate authority or when a certificate expires. When you replace a certificate for a vRealize Automation component, trust relationships for other vRealize Automation components are updated automatically.

For instance, in a distributed system with multiple instances of a vRealize Automation appliance, if you update a certificate for one vRealize Automation appliance all other related certificates are updated automatically.


vRealize Automation supports SHA2 certificates. The self-signed certificates generated by the system use SHA-256 With RSA Encryption. You may need to update to SHA2 certificates due to operating system or browser requirements.

The vRealize Automation virtual appliance management console provides three options for updating or replacing certificates for existing deployments:

  • Generate certificate - Use this option to have the system generate a self-signed certificate.

  • Import certificate - Use this option if you have a certificate that you want to use.

  • Provide certificate thumbprint - Use this option if you want to provide a certificate thumb print to use a certificate that is already deployed in the certificate store on the IaaS servers. Using this option will not transmit the certificate from the virtual appliance to the IaaS servers. It enables users to deploy existing certificates on IaaS servers without uploading them in the vRealize Automation management console.

Also, you can select the Keep Existing option to keep your existing certificate.


In a clustered deployment, you must initiate certificate changes from the virtual appliance management interface on the master node.

Certificates for the vRealize Automation appliance management site do not have registration requirements.


If your certificate uses a passphrase for encryption and you fail to enter it when replacing your certificate on the virtual appliance, the certificate replacement fails and the message Unable to load private key appears.

The vRealize Orchestrator component that is associated with your vRealize Automation deployment has its own certificates, and it must also trust the vRealize Automation certificates. By default, the vRealize Orchestrator component is embedded in vRealize Automation, but you can elect to use an external vRealize Orchestrator. In either case, see the vRealize Orchestrator documentation for information about updating vRealize Orchestrator certificates. If you update or replace the vRealize Automation certificates, you must update vRealize Orchestrator to trust the new certificates.


If you use a multi-node vRealize Orchestrator deployment that is behind a load balancer, all vRealize Orchestrator nodes must use the same certificate.

For important information about troubleshooting, supportability, and trust requirements for certificates, see the VMware knowledge base article at http://kb.vmware.com/kb/2106583.