vCenter Server Converge Tool - What About My Certificates
As more customers get ready to run the vCenter Server Converge Tool in their environments, a common question that has been asked is “What Happens to my Certificates?” Well that is a good question so lets find out!
When using certificates in your vSphere Environment there have traditionally been a few ways to deploy them.
- Default VMCA
- Subordinate CA
- Hybrid Mode
- Custom Certificates
Bob Plankers has a very good post on our vSphere Blogs which cover 10 Things To Know about vSphere Certificate Management
Default VMCA
Included in vCenter Server 6.0 is a VMware Certificate Authority also known as the VMCA. This is usually used as the default unless customers have requirements to use 3rd party signed certificates. This is also the most common as you can easily download the VMCA Root Certificates from your vCenter Server and add them to your trusted root authority either manually or via group policy. This easily meets the requirements for customers who wish to “get rid of the red X” in the address bar.
In the case of vCenter Server Convergence, vCenter Server automatically regenerates any certificates and there are no additional tasks needed.
Subordinate CA
This Subordinate CA method is one that when implemented, the VMCA actually becomes a subordinate CA of your Microsoft Certificate Authority. In this case it is not recommended as it does pose some risks as you cannot actually validate from your Root CA what certificates are being issued. This also poses problems with vCenter Server convergence as VMware does not have the ability to move the Subordinate CA.
In the case of vCenter Server Convergence, VMware recommends moving to the Hybrid Certificate or Default VMCA Model. If you must continue to use Subordinate CA, you will need to Converge your vCenter Server, then change the Embedded vCenter Server to be a Subordinate CA, reissue certificates and then decommission the external PSC and Old Subordinate CA.
Hybrid Mode
Other then using the Default VMCA, the Hybrid Model is the next recommended approach. When doing a Hybrid Mode certificate setup you replace the machine certificates with 3rd Party certificates allowing all web services to be trusted, while your ESXi hosts still utilize the VMCA for certificates.
In the case of vCenter Server Convergence, as nothing is using the External PSC directly, during the vCenter Server convergence no changes are needed.
Custom Certificates
Custom certificates are one of the most difficult certificate solutions to use. This is where no Certificate Authorities are used and EVERY certificate is replaced manually. This is traditionally used only in extremely secure locations such as government.
In the case of vCenter Server Convergence, as nothing is using the External PSC directly, during the vCenter Server convergence no changes are needed.
Wrap Up
Hopefully this has helped clarify some questions around using certificates with the vCenter Server converge tool, don’t forget to review the additional resources below.
Additional Resources
- Documentation: Certificate Management Overview
- Blog: 10 Things To Know About vSphere Certificate Management
- Blog: Hybrid vSphere SSL Certificate Replacement)
- Blog: vCenter Server Converge Tool - How do I Converge an Environment Using the UI
- Blog: Understanding the vCenter Server Converge Tool
- Blog: vCenter Server Converge Tool Enhancements in vSphere 6.7 Update 2
- Product Walkthrough: Converging a Load Balanced External vCenter Deployment using the vSphere Client
- Product Walkthrough: Converging an External vCenter Deployment using the vSphere Client
- Documentation: vCenter Server Converge Tool
See Also
- vCenter Server Converge Tool - How do I Converge an Environment Using the UI
- vCenter Server Appliance CLI - JSON Creator
- Patching the vCenter Server Appliance (VCSA) using the REST API - Part 1 (Postman Collection)
- Upgrading Platform Services Controller and vCenter Server via the CLI Installer
- Patching your vCenter Server Appliance from 6.7 to 6.7a