Converting vCenter Self-signed Certs to CA-signed Certs

This post provides some high-level detail on what was required for us to migrate to CA-signed certificates on an existing vCenter Server  installation. Our overall plan was to upgrade versions of the EHC solution (EHC v3.1 to EHC v3.5) which meant that we needed to upgrade from vSphere v5, using SSO, to vSphere 6, using the new PSC (Platform Services Controller).

Not long into the EHC upgrade process (Using the super-fantastic EHC Upgrade Guide (RTFUG) by @LifeOfBrian) we realised that we needed to have implement CA-signed certs in the current environment before upgrading/migrating SSO to the new PSC. So we went about investigating what exactly would be involved to change all self-signed certs to CA-signed certs before proceeding with EHC upgrade, and then …

sadPanda

Crap, this was going to be quite involved. Apparently it’s WAAY easier to do all of this with vSphere 6, but that wasn’t of much consolation to us sitting on vSphere 5.5. Of course if we had just implemented CA-signed certificates first day, like a customer would/should, then we wouldn’t need to go through this now. Shouldda/wouldda/couldda but didn’t because it took longer, and we couldn’t be bothered at the time. Anyway, on with the job …

This is a lab environment where we are using vCenter Server v5.5 with all required roles, including SSO, installed and running on the same server.

We started with the SSL Certificate Automation Tool, which is a command-line utility that automates the Self or CA signed certificate renewal process for vSphere 5.5.

ssl-updaterTool00

The vCenter-based components that we needed to update certificate for were as follows:

  • SSO
  • Inventory Service
  • vCenter Server
  • Web Client
  • Log Browser

We followed the procedure as prescribed in VMware KB2044696, to generate the certificates for each component. Some of the high level tasks included:

  • Generate new cert for each component
  • Submit cert(s) to domain CA-server
  • Create chain from root and Intermediate certs
  • Update each cert with root and Intermediate cert detail
  • Update SSL certs and trusts

Using the SSL Certificate Automation Tool, the screenshot below was when we were generating the certificate signing request (csr) for the Single Sign-On component, and this was repeated for each of the required components.

generateRequests01_edit

After completing this for each component, we then had the rui.csr and rui.key files available, as shown below, located in each of the respective directories as specified for the different services.

csrFolders_short

 

The next step was to present each of the rui.csr to the Certificate Authority server for our domain, which would then generate and provide the actual certificate.

csrRequest00

This involved copying the contents of the rui.csr file and pasting it into the request, as shown above.

Next step required was to create a PEM certificate chain for each certificate. The chain must contain all certificates in the chain, in the order in which they lead to the root certification authority.

Creating the PEM certificate chain involves the following (taken directly from VMware KB2044696):

  1. Create a file called chain.pem, located in the folder for the service that you are creating the chain for.
  2. Open the rui.crt file in Notepad and copy the contents of the file into the chain.pem file for that service.
  3. Open the Root64.cer file in Notepad and paste the contents of the file into the chain.pem file right after the certificate section. Be sure that there is no whitespace in the file in between certificates.Note: Complete this action for each intermediate certificate authority as well.
  4. Once complete, the file looks similar to this example:

chain_pem

Once this operation has been completed for each component, we then went back to the ssl cert tool, and generated the high level tasks to be followed for each component.

ssl-updaterTool01_edit

These high level steps outline the sequence in which the required components need to be updated, involving updating the various inter-dependant trusts and SSL certs. Best advice I received was to copy these high level tasks out to a notepad and keep track of what was complete as we went along (important when you are being distracted regularly!)

HighLevelSteps

Note: Steps were included for vCenter Orchestrator and Update Manager, although we did not request them and they are not being used. We just ignored/skipped those steps as they did not apply.

Not the more exhilarating to-do list, but the sequence and operation of each of the tasks was quite straightforward and they all succeeded first time.

All-in-all it was a very interesting exercise, something that we had heard a lot about previously but never actually gone through the pain experience of it.

Very important point here is that the exact procedure, detailed in KB2044696, should be followed at all times. This post is just a quick overview of what we did in our lab.

Of course this wasn’t the end of the story for us as we then needed to update the self-signed certs all of the vRealize Suite components to CA-signed certs and reestablish their relevant trusts etc with SSO and the main vCenter server. These components included:

  • vRA
  • vRO
  • NSX
  • vR Ops
  • vRB
  • Log Insight

… and THEN we could proceed with upgrading to vSphere 6, PSC, etc etc. Will post about that another day.

Note to self: Lesson learned, go with CA-signed certs in future instead of the quick self-signed route.

Hope that helps ….

 

Advertisements

One comment

  1. Pingback: Updating Certificates for vRealize Operations Manager | Scamallach

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s