We all know the pains that vSphere Certificate management presents us with. While VMware’s Certificate Administration tool has made life a bit simpler, it is still quite a chore to generate requests, get the certificates (in the right format) and installing it in the right order. It was also quite a bit of work to plan and replace the certificates, once the expiry dates came.
With vSphere 6, VMware is making the process easier by introducing a PKI so that lifecycle of these certificates can be managed properly. There are two main components of the new structure:
- VMware Certificate Authority (VMCA), and
- VMware Endpoint Certificate Services (VECS)
VMware Certificate Authority (VMCA) is the authority which can act as a “Root” or “Subordinate” CA in the PKI chain and issues certificates for VMware solution users, machines that are running those services and also the ESXi hosts. A point to remember is that VMCA will only issue certificates to clients that can authenticate to VMware Directory Service (vmdir) in the same domain.
VMware Endpoint Certificate Services (VECS) is a client-side store for certificates, private keys and other certificate information. While use of VMCA is optional in your PKI chain (depending on design decision – later in this post), VECS is not and you must have one installed to store all certificate and keys etc.
It is important to remember that while ESXi host certificates are issued by VMCA, they’re not stored with the Directory Service or VECS. They’re stored directly on the host itself. That happens when the host is added to vCenter explicitly or as part of an install of (or upgrade to) vSphere 6.0 or later. It starts with an autogenerated one but that is replaced by one issued by the VMCA.
If your organization is going through an upgrade and does not want VMCA to handle certificates, remember to change the certificate mode on vCenter (in Advanced Settings) to “custom” mode. As VMCA is installed on the PSC (Platform Services Controller) at install time, you should really change the mode before adding more components, otherwise, VMCA will start handling their certificates by default. Of course, once in custom mode, you’re responsible for replacing the certificates yourself.
So, what are the different options available then to choose, when doing a vSphere install? Fortunately, there are four and should cover almost any policy requirement that your organization might have. They are:
- VMCA as a Root CA
- VMCA as a Subordinate CA
- External CA
- Hybrid i.e. VMCA & External
VMCA as Root CA
That’s the configuration at install time. Benefit is that it keeps certificate lifecycle management simple, especially for environments where it hasn’t been a major requirement in the past and therefore, has not got one already. However, as the certificate is not from a well-known authority, it won’t be trusted by client browsers so an additional step will be required to ensure client browsers recognise and trust the certificate. This may or may not be easy in your environment. That said, the worst is that you’ll see the annoying browser security warnings and the big red cross, every time you browse to a vSphere.
VMCA as a Subordinate CA
I think this one is a good compromise and imagine most organizations will go for. In this scenario, you can configure the VMCA to become a “Subordinate CA”. In this scenario, the VMCA root certificate is replaced by one issued by a third-party CA, already trusted by your clients. VMCA root certificate becomes a subordinate certificate in this case. Once this is in place, VMCA provisions vCenter components and ESXi hosts with certificates that include the full certificate chain. From then on, VMCA can keep managing the vCenter ecosystem and everything is trusted by the clients.
This is your traditional one where all certificates have to be replaced by one signed by a third-party CA. Like previous versions, in this case you have to explicitly replace all certificates on all vCenter components and ESXi hosts manually using the set of CLI tools provided. This method comes with its usual difficulties but might be the only way the company policy allows. In this case, you are responsible for the provisioning and lifecycle management of the certificates.
Hybrid i.e. VMCA & External
Pretty much self-explanatory but this model is where VMCA handles certificate needs for the vCenter and ESXi environments and the rest is handled by the existing External CA infrastructure.
As you can see, there are models that will suit pretty much every organisation but the decision needs to be made before installations are done as in some cases, there are benefits in having the CA configured before other services, especially in case of a fresh install. Also, in case of an upgrade, you may or may not want the existing certificates to be replaced by VMCA, depending on company policy.
There are a few other changes as well that one might keep in mind. In previous versions i.e. 5.x, there was a solution user per service i.e. one each for vCenter, Inventory Service, Single Sign On and so on. A change in vSphere 6 is that there are solution users that hold the certificate and the services (many more in vSphere 6) are consolidated behind it.
Certificate management is still pretty much command-line but is pretty extensive and fully documented. That is a bit annoying but I am sure a GUI will be introduced at some point in the future. Maybe the next update (fingers crossed!)
Hosts provisioned by Auto Deploy always get the new certificates i.e. from VMCA, as the certificate signing request is automatically submitted by the process to VMCA during provisioning and that certificate is used from then on.
There are a fair number of changes in vSphere under the hood and this is one that I think need serious consideration if you want to relieve yourself of the certificate management pains of the past. Hopefully, this post will help in explaining what are the design decisions one needs to make with regards to VMware Certificate Authority services when installing or upgrading an environment for vSphere 6.