vRealize Automation uses certificates to maintain trust relationships and provide secure communication among components in distributed deployments.

In a distributed, or clustered, deployment, certificate organization largely follows the three-tier vRealize Automation architecture.

  • vRealize Automation appliances
  • IaaS Web components
  • IaaS Manager Service components

In a distributed deployment, each machine in a particular tier shares a certificate. For example, each vRealize Automation appliance shares a common certificate, and each Manager Service host shares a common certificate.

When the Web and Manager Service components are hosted on the same machine, one certificate is sufficient for both tiers.

System Generated Certificates

Starting in version 7.0, if you don't provide your own certificates, the vRealize Automation Installation Wizard can automatically generate self-signed certificates and place them in the appropriate trust stores on the distributed components that need them.

If you need to update the system generated self-signed certificates with user or CA supplied certificates, see Updating vRealize Automation Certificates.

Supplying Your Own Certificates

When running the standard, manual installer, you provide your own generated self-signed certificates or certificate authority (CA) certificates.

When you provide or generate your own certificates using OpenSSL or another method, you can use either wildcard or Subject Alternative Name (SAN) certificates.

IaaS certificates must be multiple-use certificates. When supplying certificates, you must obtain a multiple-use certificate that includes the IaaS components in the cluster, and copy that certificate to the trust store for each component.

Load Balancers

For high availability and failover, you can add load balancers in front of distributed vRealize Automation components. VMware recommends a pass-through configuration for vRealize Automation load balancers. In a pass-through configuration, load balancers pass requests to components without decryption. The vRealize Automation appliances and IaaS hosts then perform the necessary decryption.

If you use load balancers, you must include the load balancer FQDN in the trusted address of cluster multiple-use certificates.

For more information about using and configuring load balancers, see vRealize Automation Load Balancing.

Certificate Trust Requirements

The following table summarizes trust registration requirements for various imported certificates.

Import Register
vRealize Automation appliance cluster IaaS Web components cluster
IaaS Web component cluster
  • vRealize Automation appliance cluster
  • Manager Service component cluster
  • DEM Orchestrator and DEM Worker components
IaaS Manager Service component cluster
  • DEM Orchestrator and DEM Worker components
  • Agents and proxy agents

Certificate Trust and the Standard Installer

Whenever you run or rerun the standard, manual installer to create IaaS components, you must configure the certificate trust on those IaaS components. For example, you might use the standard installer to scale out an existing deployment.

  • IaaS Web and Manager Service hosts

    Import the web.pfx and ms.pfx files to the following locations.

    Host Computer/Certificates/Personal certificate store
    Host Computer/Certificates/Trusted People certificate store
  • IaaS DEM Orchestrator, DEM Worker, and proxy agent hosts

    Import the web.pfx and ms.pfx files to the following location.

    Host Computer/Certificates/Trusted People certificate store

In the Trusted People certificate store, you don't need to import the private key along with the certificate. The automatic installation process installs only the certificate in the Trusted People certificate store.