Recently I wrote about Updating CA SSL Certificates in vSphere 5.1 which applied to the Windows installable version of the vCenter 5.1 and it’s supporting components including SSO. VMware has now also released the instructions to update the CA SSL certificates in the vSphere 5.1 vCenter Virtual Appliance.
Over the past few weeks I have been working behind the scenes with a team of people at VMware spread around the globe on the process to successfully change out the self-signed certificates in vSphere 5.1. With the introduction of Single Sign-On in vSphere 5.1 the process is somewhat more complicated than vSphere 5 (ok quite a lot more complicated). But now I’m able to bring you some of the solutions you’ve all been waiting for.
The twitter wires and blogosphere were ablaze with news out of VMworld US 2012 (August 27 – 30th). This was my first ever VMworld (with hopefully many more to come), and I greatly enjoyed it and I also enjoyed meeting many of you. My direct flight home to Auckland from San Francisco on Air New Zealand was the best flight I’ve ever had, and I got a full 8 hours sleep so I didn’t have any jetlag (Thanks Air New Zealand). But this article is all about my take on the event, what I learned, and vSphere 5.1. I’ve decided to do something slightly different to others, to take it all in, and then write this roundup post VMworld. I’m also going to target this towards the relevance to production and business critical applications environments. I’ll also give you some insight into the sessions I presented, the results and my lessons learned. Read more…
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?
I’ve been updating my vCenter and ESXi certificates recently and I ran into one particular system so far that had absolutely no documentation or KB articles to help with changing default SSL certificates for CA signed ones. The system was my vCenter Server Virtual Appliance. You might remember that I wrote about this as a means of using it as the vSphere Web Client without needing an additional Microsoft Windows License and then I used it with a load balancer to Increase vSphere Web Client Availability and Scalability. But a lack of documentation wasn’t going to stop me. Being a SLES based virtual appliance though meant things were quite different when changing the certs. If you want to save yourself a lot of time changing the SSL Certificates for the vCenter Server Virtual Appliance then read on.
For those of you that follow me on Twitter you’ll know that I’ve been having some fun this week with changing out the default VMware generated SSL certificates on a greenfields deployment of vSphere 5 that will be supporting a large public cloud. Changing certificates is nothing new, and in environments that are concerned with security it is common practice. However it has been my experience that changing certificates with ESX(i) and vCenter has always been a bit of a challenge (I have done it on vSphere 4.x before this). It can be very time consuming and error prone, especially if you haven’t done it before. One of the things that makes it hard for people to get this right is that there is no one document or source of truth that explains in sufficient detail what the requirements and supported configurations are or how to implement CA signed ssl certificates in ESX(i) and vCenter Server. This has tripped up many organizations both large and small. I’m hoping that the information in this article will help and encourage more people to change out the default certs (to improve security), and make the process far more reliable and easier to achieve with vSphere 5. This article will focus on successfully changing the default VMware SSL certificates on ESXi 5 hosts with CA signed certificates using a Microsoft CA (it will also work with public and OpenSSL CAs, but I have not tested it yet).