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 http://kb.vmware.com/kb/1033575
   

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

   /opt/vmware/vcloud-director/bin/configure

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:

http://www.networking4all.com/en/support/tools/site+check/

https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=SO9557

http://www.sslshopper.com/ssl-checker.html

Another way is to use openssl s_client option:

openssl.exe s_client -connect vcd.domain.com:443

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.