SSL certificates played an important role in vSphere 5.1, and managing the certificates that the vSphere environment emerged as another challenge for most of the vsphere Admins. Replacing SSL certs in prior versions of vSphere (5.5 and 5.1) was a big headache.

Although vSphere 5.5 simplified the process of certificate replacement easy via the command line tools, but still it required a lot of steps to replace certs on each endpoint (vCenter Server, Single Sign On, Inventory Service, Web Client).

Derek Seaman’s had done an excellent service for VMware community and developed a tool (vSphere Toolkit) which further simplified the process of replacing certificate and took much of the pain out of it. You can download vSphere toolkit for previous version of vSphere from here.

In past I wrote a blogpost on how to replace vSphere (vCenter + Esxi) certificates, and you can read it from Here.

In vSphere 6 VMware tried to address SSL certificates in a different manner and made managing SSL certificates a lot easier than previous releases.

Introduction to VMware Certificate Authority (VMCA)

In vSphere 6, VMware has shipped their own certificate authority (VMCA). VMCA is a built-in certificate authority, which is included in the Platform Services Controller (PSC) service. If you are using vCenter with embedded PSC, you will have one endpoint cert to replace, and with an external PSC you will have two endpoint certificates to replace.

VMCA is itself a fully functional CA and can be used to issue certificates to all vSphere 6 components (vCenter and ESXi hosts) in your environment. VMCA dont have any graphical interface like Microsoft CA and is totally command line driven.

You can either use it as your Root CA, which is the default configuration, or it can be used as a Subordinate CA which will be signed by an Enterprise CA.

By default, the VMCA will self-sign its own certificate to be used as a CA certificate that will sign all requests for certificates. This self-signed CA certificate can be replaced by a certificate that is signed by a 3rd party root CA or your own root CA. Any certificate signed by the VMCA, which is an intermediate CA to your root CA, can then be validated by clients with the root CA and VMCA certificates installed.

To read more about deployment options for VMCA read this blog from Derek Seamen.

VMCA can be managed using certool.exe command which is located typically  in

“C:Program FilesVMwarevCenter Servervmcad”

on vCSA certtool can be found under

“/usr/lib/vmware-vmca/bin/certool”

VMware Endpoint Certificate Store (VECS)

The VMware Endpoint Certificate store (VECS) is a local repository for certificates and private keys. This is where all certificates within the PSC are stored, with the only exception of the ESXi certificates that are stored locally on vSphere hosts, so here you can:

• Store certificates and keys
• Sync trusted certificates
• Sync CRLs
• Use the UI
• Use the CLI to perform various actions

The VECS includes a number of keystores including machine SSL certificates, trusted roots, CRLs, solution users (machine, vpxd, vpx-extension, vSphere-webclient) and other keystores such as those for vVols. VECS holds stores that contain certificates and their keys. These stores are shown as below

Graphic Thanks to virtually-limitless.com

VECS itself can be managed via VECS-CLI which is located in the following directories.

“C:VMwarevCenter Servervmafdd”

You can learn more about vecs-cli by following this link from Sean Whitney.

Certificate Type in vSphere 6

There are 3 types of certificates in vSphere 6:

1. ESXi Certificate: This certificate is used by the ESXi host to encrypt nearly all communications.
2. Machine SSL Certificate: Each node (embedded installation, management node, or PSC) has its own machine SSL certificate. All services running on this node use this certificate for endpoint encryption. The vCenter service (vpxd), VMware directory service (vmdir) also use these certificates.
3. Solution User Certificates: These certificates are used for authentication to the vCenter SSO service. Once the certificate is presented to SSO, SSO will issue a SAML token. The service, such as vpxd, can then use this token to authenticate to other services. Baseline solution user certificates include vpxd, vpxd-extensions, and webclient.

With vSphere 6.0 there are more components but these components are now being grouped together into what’s being called Solution Users (SU). SUs now hold the certificate for the group rather than each component.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable