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:

1. Not following the correct procedure or steps, or missing out a step
2. Missing attributes from a Certificate Signing Request
3. CA Certificate Templates not configured correctly
4. Not using text transfer mode when copying cert files to ESX/Linux systems
5. 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.