The VMware vCenter certificate problem has bothered me since I first opened the vSphere client. I was used to seeing pop-up warnings from my browser telling me a website was not "100% kosher," but I was not used to getting such pop-ups from a Windows application. The hassle of replacing and managing SSL certificates is familiar to most VMware administrators and, until recently, VMware expended very little effort to help improve the process.
The reasons for validating the identity of the Web server you are connecting to are obvious and defined as a security best practice. Man-in-the-middle attacks can compromise your entire virtual infrastructure, so your SSL certificates should be valid and adhere to your corporate policy.
VMware has always used a Web server as the mechanism to provide the application programing interface access to your virtual environment. There are always two major components that need to be updated: The ESX(i) hosts and the vCenter Server (the management layer).
The process for replacing ESX(i) certificates has been almost identical through the years. It gets more complicated when starting on the task for vCenter.
Over the years, VMware has introduced more and more functionality into vCenter -- Update Manager, Heath Status and Inventory Service, to name just a few examples. All of these components have a Web interface and, because they are integrated with the vSphere client, if you are using a non-trusted Web certificate, you will be presented with that annoying popup a number of times.
The vCenter certificate problem continued and became even worse with version 5.0 and 5.1. More services were added (vSphere Single Sign-On), and additional Web interfaces made it even more complicated. VMware continued to supply appliances for all components, which all have Web servers and need SSL certificates. However, VMware neglected to provide a tool to manage all of these certificates.
The last straw for me was when VMware published "Implementing CA signed SSL certificates with vSphere 5.1 (2034833)." This Knowledge Base resource includes seven different documents, with over 100 steps needed to "get rid of those annoying popups." These documents were compiled approximately two months after the product was generally available and, in the interim, a number of bloggers tried to fill the void and fix the lack of proper information (and, in some cases, completely wrong information) on how to correctly deploy SSL certificates.
But the problem is not with one version, or with how we should update the certificate of one product or another. Every VMware product today uses a Web interface. As VMware adds more products, the list just gets longer and longer. I, for one, would like to have my SSL certificates valid and properly signed. So, instead of providing a document for every single product, why not provide an automated way to deliver this?
VMware made the first step with their introduction of the vCenter Certificate Automation Tool 1.0. It is a step (and only a step) in the right direction, but I would hardly consider this an optimal solution. Calling this an automation tool -- even as it requires so many manual steps -- is a misnomer.
All certificates have to be created manually before you start with the tools. That itself is a major and tedious task that the vCenter Certificate Automation Tool does nothing to help with. The tool is a mix and match of scripts, Perl and batch.
This only addresses the vCenter components, not the ESXi hosts, nor the supporting products around it.
I do know of another approach to the problem, currently in private beta -- vCert Manager, under development by VMware partner Virtual System Solutions -- that will hopefully fix this painful process. VCert Manager is supposed to supply a comprehensive and robust solution not only for vCenter, but also for all your ESXi hosts and all the supporting products.
VMware should have made it a priority to create a decent tool of its own and address this a long time ago.
The vCenter Certificate Automation Tool is not a comprehensive solution and doesn't solve the problem. It is merely a Band-Aid for a very painful problem that many admins have been battling for years.
I would hope that VMware would invest more effort to solve this problem once and for all, either by producing a proper tool of its own or by providing support to its partners to do so.
This was first published in May 2013