Virtual Volumes and VMware Certificate Authority (VMCA)

Products

• VMware vCenter Server
• VMware vSphere ESXi

Issue/Introduction

This article explains the interaction that occurs when Virtual Volumes connects to the VMware Certificate Authority (VMCA) that is part of the vSphere 6.0 environment. By default, VMCA generates all internal certificates used in vSphere environment, including certificates for newly added ESXi hosts and VASA Providers that manage or represent storage systems. Storage that supports Virtual Volumes uses a new VASA 2.0 Provider. Communication with the VASA Provider is protected by SSL certificates. These certificates come from the VASA Provider or from VMCA:

• Directly provided by the VASA Provider for long-term use, and is either self-generated and self-signed, or derived from an external Certificate Authority
• Generated by VMCA for use by the VASA Provider

Environment

• VMware vCenter Server 6.0.x
• VMware vSphere ESXi 6.0

Resolution

When a host or VASA Provider is registered, VMCA performs these steps automatically without involvement from the vSphere administrator.

1. When a VASA Provider is first added to vCenter storage management service (SMS), it produces a self‐signed certificate.
2. After verifying the certificate, SMS requests a Certificate Signing Request (CSR) from the VASA Provider.
3. After receiving and validating the CSR, SMS presents it to VMCA on behalf of the VASA Provider, requesting a CA signed certificate.
   VMCA is configured to function as a standalone CA, or as a subordinate to an enterprise CA. If you set up VMCA as a subordinate CA, VMCA signs the CSR with the full chain.
4. The signed certificate along with the root certificate (for signing) is passed to the VASA Provider, so it can authenticate all future secure connections originating from SMS on vCenter Server and on ESXi hosts.