vCenter 5.1, Multisite SSO, Linked Mode, Custom SSL certificates, protected by vCenter HeartBeat. Part 3

I’ve been a bit distracted lately and wasn’t able to get this written up as soon as I would have liked, but in any case here is the final part in my three part series of setting vSphere 5.1 with vCenter Heartbeat and custom SSL certificates. Part one can be found here and part two here.

The most important part of this is to remember to install all the components and then go back and replace the certificates. If you install a component, say SSO, then replace its certificate then install another component, like vCenter, the Inventory Service or the Web Client, the install will hang when they try to register with the SSO server.

Like I mentioned in part 2 the KB Article on replacing these certificates is pretty spot on, but is a little cumbersome in areas and those are the areas I’m documenting here, otherewise I’ll just link to the corresponding KB.

So getting to it. We should have at least SSO, the vCenter Inventory Service, vCenter Server, and the Web Client installed.

We need to have our Root and Intermediate certificates for this process. More then likely you have these on your Windows server or workstation already, if not you can get them from your Root CA server. Assuming you do have these already installed:

  • Open mmc.exe
  • Add the certificates snap-in
  • Choose computer account when prompted
  • Navigate to Trusted Root Certificate Authorities and open the Certificates folder under it
  • Find your Root and any Intermediate certificates, one by one right click and choose Export under All Tasks
  • Choose Base-64 encoded X.509 (.cer)
  • Save each one, if you only have a Root with no Intermediates save it as Root64.cer
  • If you have Intermediates, once all are saved you need to combine them into one file, this can be done from the command line by running copy file1.cer+file2.cer Root64.cer
  • Copy the Root64.cer file to the certs folder on the machine you’re going to use openssl on

I would recommend using a Mac or a linux box for this, it is possible to do with Windows but the tools are built into to OS X and Linux and just makes the process a little easier. We’ll start by following this KB on creating some configuration files for each component. I create a certs directory in my OS X home folder and then inside of it create a sub-folder for each service (SSO, Inventory, vCenter, etc.). In each of those folders create the cfg file for that service, all cfg files are the same except for the servers name and the organitionalunitname, the organizationalunitname field specifies the service the cfg file is for, use the following values:

  • SSO = vCenterSSO
  • Inventory Service = vCenterInventoryService
  • vCenter = vCenterServer
  • Web Client = vCenterWebClient
  • Log Browser = vCenterLogBrowser
  • Update Manager = VMwareUpdateManager

Copy and paste the following to make your cfg files, replace the italicized text with the correct values for your installation.

[ req ]
 default_bits = 2048
 default_keyfile = rui.key
 distinguished_name = req_distinguished_name
 encrypt_key = no
 prompt = no
 string_mask = nombstr
 req_extensions = v3_req

[ v3_req ]
 basicConstraints = CA:FALSE
 keyUsage = digitalSignature, keyEncipherment, dataEncipherment
 extendedKeyUsage = serverAuth, clientAuth
 subjectAltName = DNS: ServerShortName, IP: ServerIPAddress, DNS: server.domain.com

[ req_distinguished_name ]
 countryName = Country
 stateOrProvinceName = State
 localityName = City
 0.organizationName = Company Name
 organizationalUnitName = Service
 commonName = server.domain.com

Now that we have all of our request templates (cfg files) we need to generate our Certificate Signing Request or CSR. Run the following two commands against each template.

openssl req -new -nodes -out ~/certs/serviceDirectory/rui.csr -keyout ~/certs/serviceDirectory/rui-orig.key -config ~/certs/serviceDirectory/service.cfg

openssl rsa -in ~/certs/serviceDirectory/rui-orig.key -out ~/certs/serviceDirectory/rui.key

In my case the commands for SSO would look like this:

openssl req -new -nodes -out ~/certs/sso/rui.csr -keyout ~/certs/sso/rui-orig.key -config ~/certs/sso/sso.cfg 

openssl rsa -in ~/certs/sso/rui-orig.key -out ~/certs/sso/rui.key 

In the sso folder you’ll see the files rui-orig.key, rui.csr, rui.key, sso.cfg. You’ll take the rui.csr file and use it to get your certificate.

When downloading your certificate from your CA you’ll want to download it in Base-64 format, save it to the service (sso, vCenter, etc..) folder as rui.crt.

Next we need to create a PKCS #12 file for each service, run the following command to generate it:

openssl pkcs12 -export -in ~/certs/serviceDirectory/rui.crt -inkey ~/certs/serviceDirectory/rui.key -certfile ~/certs/Root64.cer -name "rui" -passout pass:testpassword -out ~/certs/serviceDirectory/rui.pfx

In my case the command for SSO would look like this:

openssl pkcs12 -export -in ~/certs/sso/rui.crt -inkey ~/certs/sso/rui.key -certfile ~/certs/Root64.cer -name "rui" -passout pass:testpassword -out ~/certs/sso/rui.pfx 

It’s very important that you do not change the password, it must remain testpassword.

Lastly we need to create the Java Key Store for SSO, run the following commands to generate it:

keytool -v -importkeystore -srckeystore ~/certs/sso/rui.pfx -srcstoretype pkcs12 -srcstorepass testpassword -srcalias rui -destkeystore ~/certs/sso/root-trust.jks -deststoretype JKS -deststorepass testpassword -destkeypass testpassword

keytool -v -importcert -keystore ~/certs/sso/root-trust.jks -deststoretype JKS -storepass testpassword -keypass testpassword -file ~/certs/Root64.cer -alias root-ca

When you have run those two commands run the following to verify all certificates are in the store:

keytool -list -v -keystore ~/certs/sso/root-trust.jks

We now have all the certificates generated and are ready to replace the self signed certificates with our CA generated ones. Copy the folder under our certs folder to the corresponding server, for example the sso folder is copied to the SSO server.

In each of the following KB’s it’s assumed that you don’t have the Root and any Intermediate certificates installed, in most organizations this isn’t true and you can skip the steps about importing Root64.cer into your Trusted Root Certificate Authorities keystore, though verify your servers do have these certificates.

Replace the certificate for the SSO by following the steps in KB 2035011, I’ve found that since our Root64.cer already contains our Intermediate certificates steps 24-28 aren’t required. Also since we haven’t done the vSphere Web Client yet you can’t do step 29-37, instead run the cli command listed under step 37.

Next do the vCenter Inventory service by following the steps in KB 2035009.

Next do vCenter by following the steps in KB 2035005.

Next do the vSphere Web Client and Log Browser by following the steps in KB 2035010.

Lastly do vCenter Update Manager by following the steps in KB 2037581.

Since we used vCenter Heartbeat in our configuration if you want to change the certificate for it you can do so by following the steps in KB 2013041. The one thing with this is it states if you don intend to change the password you need to edit Server.xml. In vCenter HeartBeat 6.5 there is a randomly generated password that is in Server.xml, so you’ll need to open that file and note the password and use it in place of password.

And last but not least if you are planning on using SRM in this environment you must specify a CA generated certificate for it during install or your sites will not pair. KB 1008390 explains the requirements for the certificate but doesn’t give a good step by step, luckily this post in the VMware Communities sums it up pretty well.

And that sums up our install of vSphere 5.1 using vCenter Heartbeat and custom SSL certificates.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.