Site icon Chris Colotti's Blog

How To: Replace vCloud Director Self Signed Certificates

Question:  How many of you have installed vCloud Director and just for the sake of getting it running generated the Self Signed Certificates, but now you want to change them over to real ones?  In addition to that you ended up pretty much screwing it all up with multiple certificates.ks files, multiple certificates in a single keystore, or just had no idea where the keystore was located?  Guess what……it has happened to a lot of us so don’t feel bad…..it will be okay.

I actually ran into this situation the other day which seems to be pretty common when dealing with the SSL certificates on the vCloud Director Cell servers.  We learned is there is a lot of details about generating certificates, but if you are not careful there is some potential for cross-over and confusion especially if you already had generated the certificates as self signed in order to just get rolling.  Some of this is also discussed in the vCloud Director Security Hardening Guide, however it does not detail the specific steps.

The first thing to note is that when you run any of the commands to create a certificate, either self signed or to generate a Certificate Signing Request (CSR), the certificates.ks file will be dropped into whatever directory you happen to be sitting in.  Generally we have been recommending to customers to create this in /opt/vmware/cloud-director with version 1.0.1.  Now if you have been part of the 1.5 BETA you will notice that the directory has changed to /opt/vmware/vcloud-director.  When you upgrade the old directory will remain and the certificates will still be in there.  However lately I have been telling people to either move the certificates.ks to /opt/vmware since that is more generic.  If you do happen to be in another directory when you run the commands you can always copy the certificate file.

Assuming you have already created self signed certificates and you have a valid certificates.ks file the process is pretty simple and you actually have two options:

  1. Keep the certificate store intact to preserve the self signed certs
  2. use the same keystore to import signed certificates

Keep the original store intact and generate a whole new one:

  1. Stop the vCD Cell Services
  2. Move, Copy, or rename the current certificates.ks file
  3. cd /opt/vmware (This is where I recommend putting the keystore file)
  4. Perform all the steps located in the KB Article for creating new certificates
  5. Re-run the configuration script (Especially if you have CHANGED the location of the certificates.ks file), but this should also update the database connections.
  6. Start the vCD Cell Services
Keeping both a keystore with self signed and real signed certificates might be useful in situations where you want to test moving from one set of certificates to the other.

Use the original store to import the signed certificates:

  1. Stop the vCD Cell Services
  2. Perform ONLY CSR generation steps located in the KB Article and reference the existing keystore file and location
    1. I still recommend moving the keystore to /opt/vmware, but that is just me
    2. If you were not sure what directory you were in when you created it, which is a common mistake you can use this to locate it:
    3. # find / -name certificates.ks
      /opt/vmware/certificates.ks
    1. There is no need to run the steps to create self signed certificates as they already exist
  1. Re-run the configuration script (Especially if you have CHANGED the location of the certificates.ks file), but this should also update the database connections.
  2. Start the vCD Cell Services
  3. This will maintain a single keystore file only

You can always check the contents of any keystore by running:

/opt/vmware/cloud-director/jre/bin/keytool –storetype JCEKS –storepass -keystore –list

You would then see an output like this:

consoleproxy, Mar 4, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): 70:D7:AB:25:D0:73:D7:74:3F:C0:68:28:15:EA:3B:DE
http, Mar 4, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): DB:14:7A:3E:4E:BD:38:B1:65:AF:5C:91:BD:44:0C:24
Exit mobile version