Replacing vCloud Director certificates

I assume at this step that you already know the vCloud component architecture.

This post aims at describing the different steps to follow when it comes to replace vCloud Director SSL certificates and configure the load Balancer (Netscaler in this post).

We’ll see how to :

  1. Create the Private Key
  2. Create the CSR
  3. Check the signed certificates
  4. Implement the certificates in the cells
  5. Export the keystore for the load balancer, Netscaler in my case.
  6. Import the keystore in Netscaler.
  7. Bind the certificates to the Virtual Server.
  8. Configure vCloud public URLs

CREATE THE PRIVATE KEY

Open a SSH session as the root user on the first cell and go to /opt/vmware/vcloud-director/jre/bin.

Then, run the following two commands to generate respectively http and consoleproxy private keys. Enter a name for a new keystore so you can revert (do a rollback) in case of any failure during the certificates replacement process

./keytool -keystore keystoreName.ks -storetype JCEKS –storepass password -genkey -keyalg RSA -keysize 2048 -alias http

       ./keytool -keystore keystoreName.ks -storetype JCEKS –storepass password -genkey      -keyalg RSA -keysize 2048 -alias consoleproxy
Please notice that the aliases  cannot be customized and must be http for the web portal service and consoleproxy for the VMRC console proxy service.

You will be prompted and will have to provide information to build the DN of the certificate.

At the question “What is your first and last name?“, type the FQDN of either the cell or the load balancer virtual server.
For exemple vcloudlb.domain.com for http service and vcloudcplb.domain.com for consoleproxy service.

CREATE THE CSR

It is time now to create the certificate signing request for each service. As vCloud Services will be load balanced, the certificates must be done for the public adresses of vCloud Director.

Still from the same SSH session and the same folder, enter the following commands to start the CSR creation wizard :

  • For the http service :
 ./keytool -keystore keystoreName.ks* -storetype JCEKS –storepass password -certreq -alias http -file outputFile.csr
  • For the consoleproxy service :
  ./keytool -keystore keystoreName.ks* -storetype JCEKS –storepass password -certreq -alias consoleproxy -file outputFile.csr
*Both http and consoleproxy certificates must share the same keystore !

Once both web and console proxy services CSR have been done, we have to transmit them to the team in charge of issuing the certificates.

CHECK THE SIGNED CERTIFICATES

The certificates have been delivered. Before importing them in vCloud, we should check that they are correct.

Ensure that in the Subject propertie, the Common Name (CN) value is the public FQDN of the service. For exemple vcloudlb.domain.com for http service.

IMPLEMENT THE CERTIFICATES IN VCLOUD DIRECTOR CELLS

Once checked, they must be imported according the following order :

Root  => Intermediate (if any) => http and consoleproxy (for the last two, the order doesn’t matter)

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import –alias root –file RootCertificate.cer

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import –alias intermediate –file IntermediateCertificate.cer

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import –alias http –file httpCertificate.cer

./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –import -alias consoleproxy –file consoleproxyCertificate.cer

We can now list the content of the keystore and verify the registered certificates

 ./keytool –storetype JCEKS –storepass password –keystore keystoreName.ks –list

Last step, reconfigure vCloud application to take in account the new certificates

Stop the application

If they have been properly issued, we have to gracefully stop the vcloud services on the first cell. To do so, go to folder  /opt/vmware/vcloud-director/bin and run the following commands :

  • ./cell-management-tool cell -u administrator -p password  –status to verify the current jobs status
  • ./cell-management-tool cell -u administrator -p password –quiesce true to prevent any new task from being started
  • ./cell-management-tool cell -u administrator -p password –shutdown to shutdown the cell
  • service vmware-vcd status  to ensure that vCloud services are effectively stopped.

Register the new certificates in the application

Launch the configuration tool : /opt/vmware/vcloud-director/bin/configure*

Give the path of the new keystore and the relevant password

Once the database updated, you are prompted to start the service, accept.

Copy the new keystore on every other cells and repeat steps “Stop the application” and “Register the new certificates in the application”.

!! For security reason, it is recommended to move the keystore file in a secured place (out of the cells).
Moving the keystore doesn’t affect the cell behaviour. During a “configure” operation, a binary file is created for each certificate (saved as certificates and proxycertificates files) in folder /opt/vmware/vcloud-director/etc.
* For some unknown reason, sometimes the path for the keystore is not prompted. When this occurs, just :

Edit the file /opt/vmware/vcloud-director/etc/global.properties and comment the lines related to the existing keystore path and password :

user.keystore.path = xxxxx

user.keystore.password = xxxxx

Relaunch the configure tool.

EXPORT CERTIFICATES FOR NETSCALER

In order to implement load balancing of vCloud Director on Nestcaler we have to :
– Export the private key of each certificate.
– Get a copy of the root and if any, the intermediate certificate.

From a SSH session (as a root user) on one cellule, go to the folder /opt/vmware/vcloud-director/jre/bin

Run the command

 ./keytool -v -importkeystore -srcstoretype JCEKS -srckeystore /App/install/backup/NewSignedCertificates.ks -srcalias http -destkeystore /App/install/NewSignedCertificates.p12 -deststoretype PKCS12

This command will export the certificate of the web portal service and its private key

You will have to provide a password for the new keystore (the P12 one that will be generated)and the password of the existing keystore ( the JCEKS one) As the monitoring of the console proxy is done on the TCP socket, we do not have to export de consoleproxy private key and certificate.

We can now verify the content of the p12 keystore with the command

We can see that the private key is available !

Next step :
Import the certificate and its private key in the Netscaler keystore.

IMPORT CERTIFICATES IN NETSCALER

From your Netscaler interface (default credential are nsroot/nsroot at least til version 11.1.48.10, the one i used for this post)

First check that the CA Root certificate is installed in Netscaler.

=> Go to Traffic Management >> SSL >> Certificates >> CA Certificates

Then, add you server certificate

=> Go to Traffic Management >> SSL >> Certificates >> Server Certificates

=> Click on Install button

Type an explicite name for the certificate

Locate your certificate and provide the password of your keystore.

You can now install the certificate

Your certificate is now available in Netscaler and can be added to a virtual server.

Next Step :
Bind the new certificate to the vCloud HTTPS* virtual server.

*You might be confused because the alias of the certificate is “http” but just keep in mind that HTTP requests are redirected to the HTTPS port of the cell.

BIND VIRTUAL SERVER CERTIFICATE

Once the vCloud http certificate has been installed in Netscaler, we have to link it to the vCloud HTTPS virtual server.

A procedure to implement vCloud load balancing in Netscaler is available here.

=> Go to Traffic Management >> Load Balancing >> Virtual Servers

Select your vCloud Virtual Server

Look at the state : Red because the virtual server does not have any server certificate

In the Certificate section, click on No at the line “No Server Certificate” so you can add the new certificate.

Then select the appropriate certificate and click on the Select button (no need to click on install as we’ve already installed it just before)

Finally, bind it.

Notice at this step that if you have not already bound the CA certificate you will have to add it too. (just click on No at the No CA Certificate)

Once the bind has been done, we can validate the virtual server modification by clicking on “Done” button at the bottom of the page.

You can now notice that your Virtual Server is now displaying a green status

Let’s now try to connect to vCloud using the virtual server FQDN

If you have a security alert, just ensure that the Root CA certificate id installed on your computer and that you typed the right URL (must match with the subject (or common name) of the certificate)

CONFIGURE VCLOUD PUBLIC ADDRESSES

Below an example of a typical configuration. Make sure to respect the format of the information you provide.

March 5th, 2017 by