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

About this task

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 self-signed certificates. Signed certificates provide the highest level of trust.

Important:

These examples specify a 2,048-bit key size, but you should evaluate your installation's security requirements before choosing an appropriate key size. Key sizes less than 1,024 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 this 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. 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.

  • Certificates for both endpoints must include an X.500 distinguished name. Many certificate authorities recommend including an X.509 Subject Alternative Name extension in certificates they grant. 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. Be sure to 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 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. Be sure to 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:vcd2.example.com,dns:vcd2,ip:10.100.101.10"
  3. 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
  4. 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
  5. Send the certificate signing requests to your Certification Authority.

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

  6. When you receive the signed certificates, import them into the keystore file.
    1. 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
    2. (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
    3. 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
    4. 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
  7. To verify that all the certificates are imported, 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 will need the keystore path name when you run the configuration script. See Configure Network and Database Connections.