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

8 comments

  1. Have u tried this. Not sure about 1.5 but in 1.0 if you change the cert you have to setup everything again as supposedly it uses the encryption for the database. Once you change the cert it can’t read it anymore. Hopefully it’s changed for 1.5.

    • We have done this at multiple customers and Step #5 which is to re-run the configuration script is required for that reason (as well as if the location is different). Simply re-running the config script on a vCD cell that is already configured should update the connections, and in most cases this process should only be a one time event to flip over from self signed to real certs.

  2. The database encryption key is stored in system.info value of the global.properties file, as opposed to the certificates.

    So if the database connectivity details haven’t changed running the configure script again will use the existing values and only prompt for a new certificates file.

    • Indeed. I have not seen any customers change the DB connection connectivity details yet, just the need to update the SSL certs. I think there is a KB on changing the DB connection though which is separate.

  3. Thanks for the guide i will have a loook at this later when im back from work. I could not get this to work last night it might have been me.

  4. Hi Chris, need your help. since i know the SSL certificate for vCloud Director is invalid. i was asked to regenerate. but i got wrong information regarding instance for the MSSQL. after i regenerated it and vcd service going up. i can’t access the vcloud director URL. could you help to resolve the problem

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Scroll To Top
%d bloggers like this: