vCloud Director and SSL Certificates

There is always a time during production deployments of vCloud Director when the question of security comes up. One of the most basic things, how to harden vCloud Director is to correctly configure SSL certificates.

VCD Cell SSL Certificates

The communication between the end-user and vCloud Director cell (either GUI or API) is encrypted and by default self-signed certificates are used. The certificate replacement procedure is explained in the documentation in a few simple steps. The problem I have encountered during big vCloud deployments is that enterprise security teams have specific procedures how to create and distribute certificates which is different from those described in the documentation.

The default procedure is following:

  • create untrusted certificates (private and public key) with JAVA keytool command (this must be done for vCloud Director GUI and console proxy)
  • create certificate signing requests
  • send the certificate signing requests to your Certification Authority
  • import the Certificate Authority root certificate
  • import signed certificates

In my case the certificates were created for me by the security team and I have received the private key in a .key file. On top of that the Certification Authority which signed the certificates was intermediate and was signed by two others. The chain was following: public Root CA -> intermediate CA1 -> intermediate CA2 -> VCD certificate.

vCloud Director JAVA keytool command does not allow private key import. Also the whole trusted chain for the certificate must be built so all the intermediate certificates are presented to the client browsers and the vCloud Director certificate can be validated. This has been achieved with the following procedure:

  1. Concatenate all CA certificates to create the whole chain:

    cat CA2.cer CA1.cer RootCA.cer > chain.crt

  2. With openssl create PKCS12 keystore with the private key, certificate chain and proper alias (first for the GUI):

    openssl.exe pkcs12 -export -in http.crt -inkey http.key -CAfile chain.crt -name http -passout pass:<password> -out http.pfx -chain

  3. Repeat for the console proxy:

    openssl.exe pkcs12 -export -in consoleproxy.crt -inkey consoleproxy.key -CAfile chain.crt -name consoleproxy -passout pass:<password> -out consoleproxy.pfx –chain

  4. Now we can import the two PKCS12 keystores into JAVA JCKS keystore with keytool:

    /opt/vmware/vcloud-director/jre/bin/keytool -importkeystore -deststorepass <password> -destkeystore certificates.ks -deststoretype JCEKS -srckeystore http.pfx -srcstoretype PKCS12 -srcstorepass <password>

    /opt/vmware/vcloud-director/jre/bin/keytool -importkeystore -deststorepass <password> -destkeystore certificates.ks -deststoretype JCEKS -srckeystore consoleproxy.pfx -srcstoretype PKCS12 -srcstorepass <password>

  5. We can check if the import was successful:

    /opt/vmware/vcloud-director/jre/bin/keytool -storetype JCEKS -storepass <password> -keystore certificates.ks –list

  6. Now we can import the new certificates to the vCloud Director cell. To do that we need first to stop it:

    service vmware-vcd stop

    Note this will interrupt all running VCD jobs. In order to do graceful shutdown follow

  7. Rerun configuration tool and point to the certificates.ks keystore created in steps 2 and 3. This will import the certificates.


  8. Repeat for the other VCD cells

How can we check the certificates can be properly validated by all clients? The best is to use external certificate checking tool which is not ‘polluted’ by intermediate certificates that might be downloaded via other means. Here are some of them:

Another way is to use openssl s_client option:

openssl.exe s_client -connect

The output should show the whole chain and the root certificate.

You can also try to upload an iso into vCloud Director catalog. The upload actually uses Java script which is not affected by the certificates from Windows store. Note: if you are still running vCloud Director 1.5.0 you can encounter digital signature error of VMware vCloud Director File Transfer Client which expired March 31 2012. This is unrelated to certificate replacement and has been fixed in VCD 1.5.1 where proper time stamp was included in the applet digital signature.

vCenter Certificate Checking

There is also possibility to enforce certificate validation for communication between vCloud Director cells and vCenter(s) or vShield Manager(s). This makes sense as vCloud Director cells are placed in DMZ zone and Man-in-the-middle attack could be used. The descriptions how to do this is in the VMware vCloud Director Security Hardening Guide 1.0). The VCD 1.5 specific version is not public yet (as of May 2012) but the procedure is the same. It requires creation of JCEKS format keystore with CA certificate that was used to sign vCenter and vShield Manager certificates and importing it via VCD – Administration – General GUI. Do not forget to use Subject Alternate Name option when creating vShield Manager certificate to include IP address as well as FQDN.

8 thoughts on “vCloud Director and SSL Certificates

  1. Hello

    I am reading your articles and they are very good. I have the following doubt with the certificates.

    If my externally published domain is and clients see my external portal, but the cells are in an internal dns with the name cell01.internal.local where the vcenter management network is in the same domain. internal.local, when using wildcard * in the vcloud director certificates must be replaced by the wilcard or only the certificate with the NAT to the vcloud cells is published in the Firewall

    1. It depends if the LB is doing SSL termination for the UI/API traffic. If yes, then you will put * cert on the LB. If the LB is doing just pass through load balancing to cells, you will upload * cert with ‘http’ alias to each cell keystore.
      For console proxy traffic you cannot use SSL termination on LB, so you will upload the same * cert also with alias ‘consoleproxy’ to each cell keystore

  2. Hello Tomas,

    I am interested to install company signed certificate for the embedded Database.
    I found that doc:

    Don’t we need to import the certificate on each appliance in the trust store, like we have done when we were working with an external database with SSL=true ?
    Does the documentation miss that part ?

    ./cell-management-tool import-trusted-certificates –source server-pgsql.crt

    1. The appliance runs appliance-sync process that automatically updates the UI/DB cert. So you do not need to use CMT. You will have to replace /opt/vmware/appliance/etc/ssl/vcd_ova.crt on every node though.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.