Large organisations, such as banks, will have quite a few very large data centres that are sometimes located all over the world. These organisations don't fool around when it comes to infrastructures. They don't have one data centre with maybe one or possibly two vCenter Servers. No, as I said, these guys have many data centres, each filled with thousands of physical servers. They could have 5 vCenter servers in each data centre, and each one of those vCenter servers will manage say 10 HA/DRS clusters with 8 ESX host each running thousands of Virtual Machines. To top this, each vCenter server will have its own stand-alone VMware Update Manager Server. To make managing these vCenter Servers easier, they will use vCenter a linked-mode configuration. This allows them to managed all of their vCenter and VUM Servers from a single vSphere Client instance.
Now here is where the SSL certificate story makes sense. For simplicity, I'm going to scale down the numbers a bit. Let's say they have two data centres. Each data centre has two vCenter Servers and two VUM servers. These vCenter Servers are configured with linked-mode. This means that when logging into one vCenter Server, one will be able to manage four vCenter Servers and four VUM Servers from the same console. Each one of these vCenter and VUM servers will have a self generated and signed SSL Certificate that was generated and installed during the vCenter and VUM installation. So when a user logs into one of the vCenter Servers for the first time using the vSphere client, that poor user will have to click the "Ignore" button on a security warning similar to the one below a whopping eight times!!! Yes, that's right, one for every vCenter Server and one for every VUM server in linked-mode.
Replacing the original SSL certificates on the vCenter and VUM servers with SSL certificates that have been generated by a CA that has a CA certificate in the client computer's Root Certificate Authority store will prevent the message from being displayed.
When I originally set out to write a post on SSL Certificate Replacement for VMware vSphere vCenter Server and VMware vSphere Update Manager Server, I had planned to write a single blog article to cover the whole topic. However, as I started to document the procedure for replacing SSL Certificates earlier in May 2010, I realised that when all the screen captures are included (which is what I had planned for) the article was simply way too long for a single blog post. For this reason I have decided to cover SSL Certificate Replacement in separate articles all linked together to form a "tutorial" like post. I hope it works!
Anyway, I have decided to break the SSL Certificate Replacement topic down into the following "Steps":
- Prepare the Certificate Authority Server with IIS, OpenSSL and Microsoft Certificate Services
- Create a Certificate Request using OpenSSL on Windows
- Submit the Certificate Request to the Microsoft Certificate Services CA
- Create a new PFX-Formatted Certificate
- Replace the vCenter Server SSL Certificates
- Replace the VMware Update Manager SSL Certificates. (Article is yet to be published)
To create this article and screen shots, I made use of a lab that was especally prepared for this exercise. This lab contained the following components:
|Server Name||Operating System||Lab Component|
|LABDC01||Windows 2003 R2||Active Directory Domain Controller and DNS Server for the labs.uk.virtualvcp.com domain|
|LABSSL01||Windows 2003 R2||Microsoft Certificate Services and OpenSSL acting as the Certificate Server|
|LABVC01||Windows 2003 R2 x64||VMware vCenter Server 4.0|
|LABVUM01||Windows 2003 R2||
VMware Update Manager Server
|LABESX01||VMware ESX 4.0||VMware ESX Server|