vSphere certificate mechanisms

Security has become an increasingly important factor in every physical and virtual environment. You may have ended up in a discussion where someone rants at the complexity of vSphere certificates and all the problems they bring. It is certainly true in some instances, but this reaction might also be due to confusion regarding the understanding of their implementation.

vSphere provides security by using certificates to perform several operations including:

• Encrypting communications between two nodes, such as vCenter Server and an ESXi host
• Authenticating vSphere services
• Performing internal actions such as signing tokens

Replacing certificates in vSphere 5.x used to be a task you gave to someone you hated. Back in vSphere 6.0 with the PSC, VMware introduced significant changes to simplify certificate management and entice companies to secure their environments.

The main components of this are:

VMCA

The internal certificate authority called the VMware Certificate Authority (VMCA). Its role is to provide the certificates necessary for vCenter Server and ESXi. It is embedded in the Platform Services Controller (PSC), allowing for immediately securing the solution out of the box.

VECS

VMware Endpoint Certificate Store (VECS) serves as a local (client-side) repository for certificates, private keys, and other certificate information that can be stored in a keystore. You can decide not to use VMCA as your certificate authority and certificate signer, but you must use VECS to store all vCenter certificates, keys, and so on. ESXi certificates are stored locally on each host and not in VECS.

The great thing with VMCA is that it offers several methods of implementing certificates according to your internal policies and how far you want to push security.

The default method is already pretty good from a security standpoint and it’s fine to keep this default configuration as it provides the lowest overhead for certificate management, however other methods of implementing certificates are offered that are described below.

Choosing the mode depends on your company policy and requirements for the system that you are configuring.

VMCA default

This method is the default one in place when you first install or deploy the vCenter Server. The VMCA will provide and sign the Machine SSL and the solution users certificates. The VMCA generated certificates and the VMCA root certificate expire after 10 years so you should be fine on that front.

Although not very useful, it is possible to generate new VMCA-signed certificates using the CLI tools. This could be useful to tweak the VMCA parameters of the signed certificates if the internal policy of your company requires certificates to be clearly identified.

VMCA Enterprise

In this Enterprise mode, the VMCA acts as an intermediate CA of the company Root CA. It is well suited to those with a solid internal PKI in place who want to keep an eye on the certificates in use in the environment, but don’t want the overhead of replacing and managing every single vSphere certificate.

To implement this model, the VMCA Root certificate has to be replaced with a certificate that is signed by an enterprise CA or third-party CA. The VMCA will then sign the custom root certificate each time it provisions certificates, making VMCA an intermediate or subordinate CA.

Custom

If your company has strict requirements in terms of certificate management, you may have to sign all the certificate yourself with your internal CA. The Custom mode will allow you to do that by completely bypassing the VMCA. Some might say “overkill”, but this is definitely the most time consuming and operationally heavy of them all. However, it is also the one that provides the highest level of security.

Unlike the VMCA methods described previously, in this model you have to sign and replace each certificate yourself. This includes the internal vCenter certificates as well as ESXi hosts certificates. Note that you can let the VMCA replace the ESXi hosts certificate but it wouldn’t make much sense. As you can see it can quickly become a huge task according to the size of the environment.

Hybrid

In this model, the VMCA supplies some of the certificates, but custom certificates can be used for other parts of the infrastructure. For example, because solution user certificates are used internally to authenticate to vCenter Single Sign-On, VMCA can very well provision those certificates. However, replace the machine SSL certificates with custom certificates will secure all SSL traffic.

The hybrid certificate is probably the best-suited method for most implementations. It’s easier to implement than the other ones and provides a reasonable amount of security that should satisfy your security officer.

The main benefit of the hybrid mode is that it minimizes the operational overhead, and secures all traffic. The hybrid deployment leaves only internal traffic to use the default VMCA-signed certificates. This method is recommended by VMware.

Conclusion

Before vSphere 6.x, custom certificates was the only way to go in this aspect and was a horrible and convoluted task to do. It is probably why many companies are still reluctant to use certificates in their vSphere environment as it feels cumbersome to implement and add a layer of complexity to the administrators. Although it is true to a certain extent, certificate replacement has been greatly simplified with the certificate-manager CLI tool and is now the case of a single certificate to replace (hybrid mode).

Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.