ssl certs – Long White Virtual Cloudsu by

Common Mistakes Implementing CA Signed SSL Certs in vSphere

Michael Webster — Wed, 07 Mar 2012 01:01:44 +0000

Changing SSL Certificates in vSphere environments can be difficult and error prone. But when I come across a problem where a customer is not able to successfully update their certs it’s generally down to one of four things. This article will provide you with the top 5 mistakes that are commonly made and how to avoid them.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. This will remove the chances of making most of the top 5 mistakes listed below.

Top 5 Common Mistakes when Implementing CA Signed SSL Certs in vSphere:

Not following the correct procedure or steps, or missing out a step
Missing attributes from a Certificate Signing Request
CA Certificate Templates not configured correctly
Not using text transfer mode when copying cert files to ESX/Linux systems
Not having the full CA key chain in the certificate

Not following the correct procedure or steps, or missing out a step

For this you could be forgiven. The vSphere documentation is not complete and is not easy to follow. The multitude of KB’s are also not complete and not always easy to follow. After the attention I’ve bought to this topic improvements are being made and it will be a lot better in the future. There are a lot of detailed steps that need to be followed. Even my blog posts on this topic (which have now been tested quite a few times) have gone into a lot of detail. One missed step or incorrect step can cause the entire operation to fail. So best not try and do this during a period where you’re sleep deprived. The best advice here is to follow the steps in my blog articles (Refer to the posts listed Updating CA SSL Certificates in vSphere 5) carefully and watch out for updated VMware documentation and KB articles. Always have a backup of previous certs and always try updating certs in a test environment before doing it in production. Make sure when you are requesting and generating your certificates that you select the correct template. You need to use a template is based on the standard Web Server (Assumes Windows CA). Make sure the password in the PFX file is ‘testpassword’ and make sure the certificates are downloaded in PEM base-64 encoded format.

Missing attributes from a Certificate Signing Request and CA Certificate Templates not configured correctly

Common Mistake 2 and 3 can generally be combined into one area as they are generally around missing attributes or incorrect configuration

For the Certificate Signing Request and the CA Certificate Template they should have the following:

keyUsage            = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment # digitalSignature, keyEncipherment, dataEncipherment are Mandatory, nonRepudiation Optional
extendedKeyUsage        = serverAuth, clientAuth # Mandatory
subjectAltName       = DNS:updmgr.homedns.org, DNS:updmgr # Optional, except with SRM

Make sure that you’re Windows CA Certificate template has the option “Allow Key Exchange Only With Key Encryption” selected in its key usage policy. It will not work without this.

You need to verify your certificates when you get them back from your CA to ensure that they include the correct fields and that all fields are populated correctly. The above are in addition to the normal request fields that are necessary for the CSR. You’ll find more information on my previous posts. Refer to the posts listed Updating CA SSL Certificates in vSphere 5 especially regarding vCenter.

Not using text transfer mode when copying cert files to ESX/Linux systems

This is probably one of the biggest catches when updating SSL Certificates, especially when they are generated in a Windows system and then copied to an ESX/ESXi or Linux system. The ASCII text file formats are a little different. If you don’t use text mode file transfer in WinSCP or other secure copy tools you will find additional unwanted characters in your certificate files. This will corrupt the file and render it useless unless corrected. Fortunately this is very easy to correct. Either copy the files again using text mode file transfer, or alternatively follow the process outlined by Maish Saidel-Keesing in his recent post Removing ^M Characters from Files in ESXi at TechnoDrone.

Not having the full CA key chain in the certificate

This common mistake comes thanks to Erik Bussink. It could sort of be covered by option 1 but happens frequently enough to have a separate item. To ensure you don’t run into this make sure you download the full base-64 encoded certificate from your CA that includes the full key chain. In a Windows CA this is as simple as just downloading the base64 encoded certificate on the final page of the certificate submission workflow. This may also require importing the trusted Root Public Cert using openssl or Java keytool from the command line.

Hopefully by taking the above common mistakes into account, and by following the detailed articles I have posted on the topic you will find changing SSL certs in vSphere much easier and more successful.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Best Order for Changing SSL Certs in vSphere Environments

Michael Webster — Tue, 06 Mar 2012 10:10:53 +0000

During the process of working with customers changing their SSL default self-signed certs for CA signed SSL certs in their vSphere environments I found that the order they were changed made a difference. This was also the case when I ran through the same process in my lab environment. Here is the order that I found was the easiest when changing the SSL certs in the vSphere environments I’ve worked with.

Firstly I’d like to start by saying this is what I’ve found the easiest in the environments I’ve worked in. Your mileage may vary. I have tested this with vSphere 5, but it may also be applicable for earlier versions. I’d like to hear from you on your experience and if this has worked for you, or if you used a different order.

ESXi Hosts
vCenter Server
vSphere Web Client
Other Components, such as SRM, vCenter Operations Manger, VMware View, vShield etc

The reason I have found that this order is the easiest is because if you update the ESXi Hosts certs first with trusted CA certs they can be added into vCenter quicker. The hosts will also not become disconnected and require you to reconnect them when you change the vCenter SSL certificates. The reason why I have the vSphere Web Client listed before other components is because it will generally be installed on the same server as vCenter Server. Unless of course you have a very large number of vSphere Web Client users, which which case you will have split it out onto a separate server.

If you can update the SSL Certs on the ESXi Hosts before adding them into vCenter it will save you some time as you won’t have to fix the SSL thumbprints in the vCenter Database, which is due to be fixed in vSphere 5 Update 1 (refer to The Trouble with CA SSL Certificates and ESXi 5).

—

Why change VMware default self-signed SSL certs?

Michael Webster — Tue, 06 Mar 2012 09:21:42 +0000

I’ve written a few articles now on how to change the self-signed SSL certs in a few of the VMware components, such as vCenter Server 5, vSphere Web Client, and ESXi 5 Hosts. All without any discussion about why you would want to do it at all. So why do you bother going to all the trouble of changing out the self-signed SSL certs for Org CA or Public CA signed SSL certs?

One of the main reasons it is generally recommended is to prevent or reduce the risk of Man in the Middle (MiTM) attacks. This is where someone impersonates a valid system or communication using an untrusted or self-signed SSL certificate and in the process intercepts encrypted traffic. This is one of the things the Public Key Infrastructure (PKI) has been built to prevent. However this is one of many reasons why you would want to change the certs for valid CA signed certs.

Changing out certificates for all of the software components in a vSphere infrastructure requires a lot of effort. It can also be quite painful, although I hope my articles go some way to helping with the difficulty level. But in a lot of environments it is definitely worthwhile or required.

Instead of giving you all the reasons you might want to go to this trouble and change the certs for your organization I have instead developed a quick poll. I’d like to know from you why you do it? What motivates your organization to implement Org CA or Public CA signed SSL certs for your vSphere environment and the various components?

Let me know your top 5 reasons below (Select up to 5 options from the list):

Changing vCenter Heartbeat to CA SSL Certificates

Michael Webster — Sun, 19 Feb 2012 01:11:25 +0000

In a previous post, The Trouble with CA SSL Certificates and vCenter 5, I reported that there isn’t a supported way to change out the self-signed SSL certificates that vCenter Heartbeat uses to communicate between nodes. This is quite important in secure enterprise and government environments, and in public/private clouds that are trying to meet regulatory standards. I have some good news to report.

After raising this with VMware I was informed they were working on a supported solution and they have now developed a KB article that explains how to change the vCenter Heartbeat SSL Certs for CA signed SSL certs. For information on how to change out the SSL certs for vCenter Heartbeat refer to KB 2013041. I have not yet tested this procedure but when I do I will update this post and if necessary create a new post to explain the process further and give you a tested and verified process.

—