Creating and importing signed certificates provides the highest level of trust for SSL communications and helps you secure the connections within your cloud. Creating and importing the certificates before you install and configure vCloud Director software simplifies the installation and configuration process.

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 can use certificates signed by a trusted certification authority, or use self-signed certificates.
Important: These examples specify a 2048-bit key size, but you should evaluate your installation's security requirements before choosing an appropriate key size. Key sizes less than 1024 bits are no longer supported per NIST Special Publication 800-131A.

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

Prerequisites

  • Generate a list of fully qualified domain names and their associated IP addresses on vCloud Director server.
  • Choose an address to use for the HTTP service and an address to use for the console proxy service. See Create SSL Certificates.
  • Verify that you have access to a computer that has a Java version 7 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 7 runtime environment installed. Certificates created with a keytool from any other source are not supported for use with vCloud Director. These command-line examples assume that keytool is in the user's path. The keystore password is represented in these examples as passwd.
  • Certificates for both endpoints must include an X.500 distinguished name. vCloud Director does not require certificates to include a Subject Alternative Name.
  • Familiarize yourself with the keytool command, including its -dname and -ext options.
  • Gather the information required for the argument to the keytool -dname option.
    Table 1. Information required by keytool -dname option
    X.500 Distinguished Name Subpart keytool keyword Description Example
    commonName CN The fully qualified domain name associated with the IP address of this endpoint. CN=vcd1.example.com
    organizationalUnit OU The name of an organizational unit, such as a department or division, within the organization with which this certificate is associated OU=Engineering
    organizationName O The name of the organization with which this certificate is associated O=Example Corporation
    localityName L The name of the city or town in which the organization is located. L=Palo Alto
    stateName S The name of the state or province in which the organization is located. S=California
    country C The name of the country in which the organization is located. C=US

Procedure

  1. Create an untrusted certificate for the HTTP service.
    This example command creates an untrusted certificate in a keystore file named certificates.ks. The keytool options have been placed on separate lines for clarity. The X.500 distinguished name information supplied in the argument to the -dname option uses the values shown in the prerequisites. The DNS and IP values shown in the argument to the -ext option are typical. Include all the DNS names at which this endpoint can be reached, including the one you specified for the commonName (CN) value in the -dname option argument. You can also include IP addresses, as shown here.
    keytool 
       -keystore certificates.ks
       -alias http 
       -storepass passwd
       -keypass passwd
       -storetype JCEKS
       -genkeypair
       -keyalg RSA
       -keysize 2048
       -validity 365 
       -dname "CN=vcd1.example.com, OU=Engineering, O=Example Corp, L=Palo Alto, S=California, C=US" 
       -ext "san=dns:vcd1.example.com,dns:vcd1,ip:10.100.101.9"
    Important: The keystore file and the directory in which it is stored must be readable by the user vcloud.vcloud. The vCloud Director installer creates this user and group.
  2. Create an untrusted certificate for the console proxy service.
    This command adds an untrusted certificate to the keystore file created in Step 1. The keytool options have been placed on separate lines for clarity. The X.500 distinguished name information supplied in the argument to the -dname option uses the values shown in the Prerequisites. The DNS and IP values shown in the argument to the -ext option are typical. Include all the DNS names at which this endpoint can be reached, including the one you specified for the commonName (CN) value in the -dname option argument. You can also include IP addresses, as shown here.
    keytool 
       -keystore certificates.ks
       -alias consoleproxy 
       -storepass passwd
       -keypass passwd
       -storetype JCEKS
       -genkeypair
       -keyalg RSA
       -keysize 2048
       -validity 365 
       -dname "CN=vcd2.example.com, OU=Engineering, O=Example Corp, L=Palo Alto, S=California, C=US" 
       -ext "san=dns:vcd1.example.com,dns:vcd1,ip:10.100.101.9"
  3. Create a certificate signing request for the HTTP service and for the console proxy service.
    1. Create a certificate signing request in the http.csr file.
      keytool -keystore certificates.ks -storetype JCEKS -storepass passwd \ -certreq -alias http -file http.csr -ext "san=dns:vcd2.example.com,dns:vcd2,ip:10.100.101.10"
    2. Create a certificate signing request in the consoleproxy.csr file.
      keytool -keystore certificates.ks -storetype JCEKS -storepass passwd \ -certreq -alias consoleproxy -file consoleproxy.csr -ext "san=dns:vcd2.example.com,dns:vcd2,ip:10.100.101.10"
  4. Send the certificate signing requests to your Certificate Authority.
    If your certification authority requires you to specify a Web server type, use Jakarta Tomcat.
    You obtain the CA-signed certificates.
  5. If you obtained the signed certificates in PEM format, you must import them to a PKCS12 intermediate keystore.
    If the certificates are not in PEM format, skip to step 6.
    1. Import the PEM key and certificate for the HTTP service. Enter a password and make a note of it for later.
      openssl pkcs12 -export -in path to certificate -inkey path to private key -out http.p12 -name http
    2. Import the PEM key and certificate for the console proxy service. In many cases, this is the same key and certificate as the one for the HTTP service.
      openssl pkcs12 -export -in path to certificate -inkey path to private key -out consoleproxy.p12 -name consoleproxy
  6. Import the signed certificates into the JCEKS keystore file.
    1. Import the Certificate Authority's 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
    2. If you received intermediate certificates, import them 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
    3. Import the HTTP service certificate.
      keytool -importkeystore -deststoretype JCEKS -deststorepass keystore password -destkeystore certificates.ks -srckeystore http.p12 -srcstoretype PKCS12 -srcstorepass keystore password
    4. Import the console proxy service certificate.
      keytool -importkeystore -deststoretype JCEKS -deststorepass keystore	password -destkeystore certificates.ks -srckeystore consoleproxy.p12 -srcstoretype PKCS12 -srcstorepass keystore	password
  7. To check if the certificates are imported, run the command to list the contents of the keystore file.
    keytool -storetype JCEKS -storepass	passwd -keystore	certificates.ks -list
  8. Repeat this procedure on all vCloud Director servers in the server group.

What to do next

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 need the keystore path name when you run the configuration script. See Configure the Network and Database Connections.