As many of do, we get a solution working whether it's from vmware or other software of applciation vendors. When all is good and working, we then look to get rid of those certificate warnings and errors caused and generated by using self signed certificates. Other times, changing out the self-signed certificate is just simply required and not done just for esthetics.
This is a proceedure for replacing self signed certificates for VMWare vCloud Director 5.5 with CA signed SSL certificates.
The source for this proceedure was derived from vmware's documentation. There are a few things I wanted to add to this as the information is missing from vmware's documentation.
I hope others are able to find this post and save themselves some time. The more experienced people who are replacing the certifctae will probably be able to work their way around the small issues encountered as I did. This will help those who are more unsure (or less sure depending on how you look at it).
Four things things I wanted to add.
- Firstly, VMWare's process works. For those of you worried about something bad happening or Director breaking because of the swapping of certs, rest assured it will not (at least, it certainly did not for me).
- VMware's documentation I suspect is recycled from earlier 5.1 or earlier SSL generating documentation (at the time this post was written, vCloud 5.5 documentation was lacking and most probably will be updated). The reason for why I suspect this is because the generation of the certificate in the store is RSA and defaults to 1024 bit encryption. The certificate CA I used did not like this and wanted 2048. It just did not work with 1024. The keytool option for creating the 2048 bit encryption is not shown in vmware's documentation (it will certaintly be updated for sure).
- Some CA authorities provide us not .cer files but .crt files. VMWare's documentation shows the import of .cer files however .crt file will work just as well for the root , intermediate and your SSL site and consoleproxy service certificates.
- Confirmed, wildcard certs work without issue. Wildcard certs can be used for vCloud Director web and consoleproxy services.
Let's begin the change process
You most likely have a certificates.ks file already located somewhere on the vcloud director server's file system. It was created when you created the self singed certificates. If you did not create self signed certificates, that is okay too. A .ks (keystore file ) will be created when you follow this proceedure.
I opted to create the keystore file in the /opt/vmware folder of the vClolud Director file system logged in as root.
If there is already a .ks file there, rename it or move it out of the directory. It can get confusing if there is more than one file.
Renaming, deleting, or moving the existing certificates.ks file will not stop any services. The keystore file is used by the director configuration script then it's not touched after that unless the configuration script is run again.
My VMware vdirector server operating system is CentOS 6.4 x64. I have installed GNOME desktop and have gedit package installed as well. I have two vmware vcloud director servers both with the same version of CentOS (yes, I did the certificate swap from self-signed to CA signed on both servers).
Recall from the installation of vCloud Director that you have two network interfaces; one for the http service (alias name http) and the other for the proxy service (alias name consoleproxy).
- log in as root.
- start your linux desktop if you installed one (in my case startx gets it going) then open a terminal window to proceed.
- change directory to /opt/vmware (#cd /opt/vmware)
- confirm (#pwd )
- check for other keystores (#ls -al). This proceedure creates a certificates.ks file. If one alredy exists rename it.
1. Create an untrusted certificate in the new keystore for the HTTP service.
This command creates an untrusted 2048 bit certificate in a keystore file named certificates.ks. Note that we are using a 2048 bit encryption key. vCloud director documentation does not include the -keysize option.
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey -keyalg RSA -keysize 2048 -alias http
2. Answer the organizational keytool questions.
The keytool will ask for fist and last name, type the fully qualified domain name associated with the IP address you want to use for the HTTP service - for example vcloud.yourdomain.com (this should be resolvable from Internet but could be internal as well).
3. For the remaining organization questions asked by the keytool, provide appropriate answers for your organization and location, as shown in this example.
What is your first and last name? [Unknown]:vcloud.yourdomain.com
What is the name of your organizational unit? [Unknown]:Cloud Engineering Dpt.
What is the name of your organization? [Unknown]: your company name
What is the name of your City or Locality? [Unknown]: your city
What is the name of your State or Province? [Unknown]: your state or province
What is the two-letter country code for this unit? [Unknown]: AU, or US, or UK, etc.
Is CN=vcloud.yourdomain.com, OU=Cloud Engineering Dpt., O="your company name", L="your city", ST=your state, C=AU
Enter key password for (RETURN if same as keystore password):
4. Create a certificate signing request for the HTTP service.
This command creates a certificate signing request in the file http.csr. The CSR data is what you will provide to the CA authority when requesting the certificate from them.
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -certreq -alias http -file http.csr
5. Create an untrusted certificate for the console proxy service.
This command adds an untrusted certificate to the keystore file created in Step 1. Again, note the -keysize 2048 option.
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey -keyalg RSA -keysize 2048 -alias consoleproxy
6. When keytool asks for your first and last name, type the fully-qualified domain name associated with the IP address you want to use for the console proxy service.
7. For the remaining questions, provide answers appropriate for your organization and location, as shown in the example in Step 3.
8. 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
9. Send the certificate signing requests to your Certification Authority.
If your certification authority requires you to specify a Web server type, use Jakarta Tomcat (Apache will work too). In my case, the certificate authority did not have Jakarta Tomcat as an option. They had only Tomcat and it worked fine.
10. The CA will provide you with the signed certificates. For simplicity of this proceedure, save the files in the same folder /opt/vmware then import them into the keystore file using the following command. In addition to your SSL certificate generated by your CSR data, you will need to import your CA's root and Intermediate certificates into the store. Recall that the keystore file is new and started empty. The only things in it are what we are putting into it. Well, we need to add the CA's certs to complete the chain to our cert.
Import the Certification Authority's root certificate into the keystore file.
.crt or .cer Certificate File Type Can be Imported into vCloud Director
The following command imports the CA's root certificate from the root.cer file to the certificates.ks keystore file.
Using a .crt Certificate File for vCloud Director
a. If you were provided a .crt file, use that file. You don't have to convert it or rename it to another extension. If the name of the root certificate is not root.cer or root.crt then change the command below to use the name provided or rename your file to root.cer or root.crt to match the command for simple copy and paste.
keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias root -file root.cer
b. (Optional) If you received intermediate certificates, import them into the keystore file.
This command imports intermediate certificates from the intermediate.cer or intermediate.crt file to the certificates.ks keystore file.
keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias intermediate -file intermediate.cer
c. Import the certificate for the HTTP service.
Now it's time to import your SSL certificate for vmware vcloud director http service to use.
This command imports the certificate from the http.cer file to the certificates.ks keystore file. If you were provided a .crt file, that is fine to use.
keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias http -file http.cer
d. Import the certificate for the console proxy service.
This command imports the certificate from the consoleproxy.cer file to the certificates.ks keystore file. Again, a .crt file is fine.
keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -import -alias consoleproxy -file consoleproxy.cer
11. To verify that all the certificates are imported, list the contents of the keystore file.
keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -list
You will see the root, intermediate and your two certificates listed in the output. Your certificates will be "private". If you are using a wildcart certificate, you will not see the FQDN names. You will see *.yourdomain.com.
After updating the SSL certificate on your vCloud Director
First stop the vzcloud director service (on Cent OS):
# service vmware-vcd stop
Rerun the "configure" script for director to apply the new certificate and it becomes active.