vCloud Director uses HTTPS (TLS or SSL) to secure all network traffic to all external endpoints. HTTPS is also supported for many internal endpoints, including AMQP and LDAP. It is especially important to provide a certificate signed by a well-known certificate authority (CA) for external endpoints. Internal endpoints are less vulnerable, and in most cases can be adequately secured with enterprise or even self-signed certificates.

All certificates should have a common name (CN) field that matches the Fully Qualified Domain Name (FQDN) of the server on which they are installed. Usually this implies that the server is registered in DNS -- so it has a well-defined and unique FQDN -- and also it implies that you are connecting to it by FQDN, not an IP address. If you do intend to connect using the IP address, then the certificate should include subjectAltName field that matches the host's IP address.

Additional information is available in (RFC 6125) and (RFC 5280). You should also consult your CA.

Certificates for Public Endpoints

Endpoints exposed to an enterprise network or other public network such as the Internet should be protected with a certificate signed by a well-known root CA. These endpoints include:
  • The cell HTTPS address and console proxy address. You must configure both addresses and supply their certificate and keystore details during installation.
  • SSL-terminating load balancers. See Load Balancers and SSL Termination.

In general, well-signed certificates do not need to be imported, since any SSL client can verify the trust chain all the way up to the root. Lower-level certificates (enterprise-CA or self-signed) cannot be checked in this way, have been created by your local security team, who can tell you where to import them from.

Certificates for Private (Internal) Endpoints

Endpoints on private networks, ones that are unreachable from public networks and have generally been created specifically for use by vCloud Director components such as the database and AMQP, can use certificates signed by an enterprise CA, or even use self-signed certificates if necessary. These endpoints include:
  • Internal connections to vSphere and NSX.
  • AMQP endpoints connecting vCloud Director and RabbitMQ.
  • PostgreSQL database connections (optional).

Having a signed certificate reduces the chance that a malicious application that manages to gain access to a private network can masquerade as a legitimate vCloud Director component.

Supported Protocols and Cypher Suites

vCloud Director supports several HTTPS protocols, including TLS and SSL. TLS v1.0 is unsupported by default because it has known vulnerabilities. After installation, you can use the cell management tool configure the set of protocols and cypher suites that the system supports for HTTPS connections. See vCloud Director Release Notes for details.

Configuring vSphere Certificates

In vSphere 6.0 and later, the VMware Certificate Authority (VMCA) provisions each ESXi host and each vCenter Server service with a certificate that is signed by VMCA by default. You can replace the existing certificates with new VMCA-signed certificates, make VMCA a subordinate CA, or replace all certificates with custom certificates. See vSphere Security Certificates in the vSphere Security guide for more information about creating and replacing certificates used by vCenter and ESXi.

Configuring vCloud Director to Check vCenter Certificates

To configure vCloud Director to check vCenter certificates, create a Java keystore in JCEKS format that contains the trusted certificate(s) used to sign vCenter certificates. (Certificates for the individual vCenter servers are not in this store -- only the CA certificates that are used to sign them.)

A command like this one imports a PEM-encoded certificate from /tmp/cacert.pem into a keystore named myca.ks:
$ keytool -import -alias default -keystore myca.ks -file /tmp/cacert.pem -storepass password -storetype JCEKS
A command like this one adds another certificate ( /tmp/cacert2.pem in this example) to the same keystore:
$ keytool -importcert-keystore myca.ks -storepass password -file /tmp/cacert2.pem -storetype JCEKS

Once you have created the keystore, log in to vCloud Director as a system administrator. In the System Settings section of the Administration tab, click General and navigate to the bottom of the page.

Select Verify vCenter and vSphere SSO certificates and Verify NSX Manager certificates. Click the Browse button to search for your Java keystore, then click Open. Enter the keystore password and click Apply.

When the operation completes, your trusted certificates and other information are uploaded to the vCloud Director database. So you only need to do this operation once for all cells.

Once this option is turned on, all vCenter and NSX manager certificates are checked, so every vCenter and NSX manager must have a correct certificate chain and a certificate that matches its FQDN. If it does not, connections to vCenter and NSX will fail.

Important:

If you have changed certificates after adding vCenters and NSX managers to vCloud Director, you must force reconnection to the servers.

Updating Certificates and Keys for vCloud Director Cells

Each vCloud Director server requires two SSL certificates, one for the HTTP service and one for the console proxy service, in a Java keystore file. You must provide the pathname to these keystores when you install vCloud Director. Signed certificates provide the highest level of trust.

The certificates command of the cell management tool automates the process of replacing existing certificates with new ones. Use the certificates command to replace self-signed certificates with signed ones or replace expiring certificates with new ones. To create a JCEKS keystore containing signed certificates, see Create and Import a Signed SSL Certificate in the vCloud Director Installation and Upgrade Guide.

To replace SSL certificates for one or both endpoints use a command with the following form:
cell-management-tool certificates options
For more information, see Replacing Certificates for the HTTP and Console Proxy Endpoints in the vCloud Director Administrator's Guide.