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 :
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.
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 :
|./keytool -keystore keystoreName.ks* -storetype JCEKS –storepass password -certreq -alias http -file outputFile.csr|
|./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.
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.
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 :
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.
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.
From your Netscaler interface (default credential are nsroot/nsroot at least til version 184.108.40.206, 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.
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)
Below an example of a typical configuration. Make sure to respect the format of the information you provide.