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.
Certificates for Public Endpoints
- 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
- 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.)
$ keytool -import -alias default -keystore myca.ks -file /tmp/cacert.pem -storepass password -storetype JCEKS
$ 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.
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.
cell-management-tool certificates optionsFor more information, see Replacing Certificates for the HTTP and Console Proxy Endpoints in the vCloud Director Administrator's Guide.