Signed certificates provide the highest level of trust for SSL communications.

Each vCloud Director server requires two SSL certificates, one for each of its IP addresses, in a Java keystore file. You must create two SSL certificates for each server that you intend to use in your vCloud Director server group. You can use certificates signed by a trusted certification authority, or self-signed certificates. Signed certificates provide the highest level of trust.

To create and import self-signed certificates, see Create a Self-Signed SSL Certificate.

Generate a list of fully-qualified domain names and their associated IP addresses on this server, along with a service choice for each IP address. See Create SSL Certificates.

Verify that you have access to a computer that has a Java version 6 runtime environment, so that you can use the keytool command to create the certificate. The vCloud Director installer places a copy of keytool in /opt/vmware/vcloud-director/jre/bin/keytool, but you can perform this procedure on any computer that has a Java version 6 runtime environment installed. Certificates created with a keytool from any other source are not supported for use with vCloud Director. Creating and importing the certificates before you install and configure vCloud Director software simplifies the installation and configuration process. These command-line examples assume that keytool is in the user's path. The keystore password is represented in these examples as passwd.

1

Create an untrusted certificate for the HTTP service.

This command creates an untrusted certificate in a keystore file named certificates.ks.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey -keyalg RSA -alias http

The certificate is valid for 90 days.

2

Answer the keytool questions.

When keytool asks for your first and last name, type the fully qualified domain name associated with the IP address you want to use for the HTTP service.

3

For the remaining questions, provide answers appropriate for your organization and location, as shown in this example.


What is your first and last name? [Unknown]:mycloud.example.com
What is the name of your organizational unit? [Unknown]:Engineering
What is the name of your organization? [Unknown]:Example Corporation
What is the name of your City or Locality? [Unknown]:Palo Alto
What is the name of your State or Province? [Unknown]:California
What is the two-letter country code for this unit? [Unknown]:US
Is CN=mycloud.example.com, OU=Engineering, O="Example Corporation", L="Palo Alto", ST=California, C=US correct?[no]:yes
Enter key password for <http> (RETURN if same as keystore password):
4

Create a certificate signing request for the HTTP service.

This command creates a certificate signing request in the file http.csr.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -certreq -alias http -file http.csr
5

Create an untrusted certificate for the console proxy service.

This command adds an untrusted certificate to the keystore file created in Step 1.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey -keyalg RSA -alias consoleproxy

The certificate is valid for 90 days.

6

When keytool asks for your first and last name, type the fully-qualified domain name associated with the IP address you want to use for the console proxy service.

7

For the remaining questions, provide answers appropriate for your organization and location, as shown in the example in Step 3.

8

Create a certificate signing request for the console proxy service.

This command creates a certificate signing request in the file consoleproxy.csr.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -certreq -alias consoleproxy -file consoleproxy.csr
9

Send the certificate signing requests to your Certification Authority.

If your certification authority requires you to specify a Web server type, use Jakarta Tomcat.

10

When you receive the signed certificates, import them into the keystore file.

a

Import the Certification Authority's root certificate into the keystore file.

This command imports the root certificate from the root.cer file to the certificates.ks keystore file.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias root -file root.cer
b

(Optional) If you received intermediate certificates, import them into the keystore file.

This command imports intermediate certificates from the intermediate.cer file to the certificates.ks keystore file.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias intermediate -file intermediate.cer
c

Import the certificate for the HTTP service.

This command imports the certificate from the http.cer file to the certificates.ks keystore file.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias http -file http.cer
d

Import the certificate for the console proxy service.

This command imports the certificate from the consoleproxy.cer file to the certificates.ks keystore file.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias consoleproxy -file consoleproxy.cer
11

To verify that all the certificates are imported, list the contents of the keystore file.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -list
12

Repeat steps Step 1 through Step 11 on each of the remaining vCloud Director servers.

If you created the certificates.ks keystore file on a computer other than the server on which you generated the list of fully qualified domain names and their associated IP addresses, copy the keystore file to that server now. You will need the keystore path name when you run the configuration script. See Configure Network and Database Connections.

Note

Because the vCloud Director configuration script does not run with a privileged identity, the keystore file and the directory in which it is stored must be readable by any user.