Learn about security improvements that vSphere Virtual Volumes storage provider, also called VASA provider, version 5 offers in vSphere 8.0 Update 1 and later releases. You can also learn about the security model in vSphere 8.0 and earlier releases.

VASA 5 Support and Security with vSphere 8.0 Update 1 and Later

All storage providers of VASA 5 and later versions use a stricter authentication mechanism, which requires ESXi to be authenticated in context of vCenter Server. VASA 5 improves security and offers a significantly modified management model that includes the following major changes:
  • For each vCenter Server that registers with the array using VASA 5 or later, the VASA provider creates a dedicated web server instance, or a virtual host, which can be either a virtual web server instance or a completely separate instance. The VASA client in vCenter Server relies on certificate based authentication and authorization to access its dedicated virtual host created on the array. All VASA client certificates, including vCenter Server and ESXi certificates, get registered with the virtual host. This creates strong isolation between different vCenter Server systems when the systems are authenticated. In addition, VASA providers can offer separate resource access and improved isolation to different vCenter Server systems.
  • With VASA 5, the VASA client uses a dedicated certificate for VASA communications. Each vCenter Server provisions a certificate for the VASA provider, which is managed through a dedicated virtual host specific to vCenter Server. All ESXi hosts that support VASA 5 use the dedicated virtual host created by their managing vCenter Server.
  • vCenter Server provisions the VASA client certificate for each new ESXi host 8.0 Update 1 or later and synchronizes the public key of the certificate with the VASA provider. In contrast with the previous security model that authenticated the CA issuer for the client certificate, the VASA provider now identifies and authorizes an individual client using the public key.
  • To comply with VMware security requirements, vSphere does not trust self-signed certificates for TLS communications. The only exception is during a short period when the VASA provider gets registered and for backward compatibility. An array administrator can use a Custom CA certificate for the VASA provider to override the self-signed certificate at array for backward compatibility and bootstrapping.
  • To avoid losing access to the VASA provider, follow these guidelines. For information, see Manage Storage Providers for vSphere Virtual Volumes.
    • Do not unregister and re-register your VASA provider to upgrade. Instead, use a proper upgrade mechanism for your VASA provider. When vCenter Server notifies you about a new available VASA version, make sure to accept this version within a reasonable time. To upgrade from the vSphere Client, use the Upgrade Storage Provider option.
    • Regularly refresh the VASA provider certificate. Make sure to refresh the certificate within a reasonable time after vCenter Server warns you that the certificate assigned to the VASA provider is about to expire. Use the vSphere Client Refresh certificate option.
    • When you renew the VMCA root certificate or vCenter Server client certificate, SMS might lose connection with the VASA provider. If the provider is offline, use the Re-authenticate vCenter Server option.
    • If a host loses authentication, you can remediate the authentication failure by using the Re-authenticate Host VASA Clients option.

Security Certificates with vSphere 8.0 and Earlier Releases

vSphere includes the VMware Certificate Authority (VMCA). By default, the VMCA creates all internal certificates used in vSphere environment. It generates certificates for newly added ESXi hosts and storage VASA providers that manage or represent Virtual Volumes storage systems.

Communication with the VASA provider is protected by SSL certificates. These certificates can come from the VASA provider or from the VMCA.
  • Certificates can be directly provided by the VASA provider for long-term use. They can be either self-generated and self-signed, or derived from an external Certificate Authority.
  • Certificates can be generated by the VMCA for use by the VASA provider.
When a host or VASA provider is registered, VMCA follows these steps automatically, without involvement from the vSphere administrator.
  1. When a VASA provider is first added to the vCenter Server storage management service (SMS), it produces a self‐signed certificate.
  2. After verifying the certificate, the SMS requests a Certificate Signing Request (CSR) from the VASA provider.
  3. After receiving and validating the CSR, the SMS presents it to the VMCA on behalf of the VASA provider, requesting a CA signed certificate.

    The VMCA can be configured to function as a standalone CA, or as a subordinate to an enterprise CA. If you set up the VMCA as a subordinate CA, the VMCA signs the CSR with the full chain.

  4. The signed certificate with the root certificates is passed to the VASA provider. The VASA provider can authenticate all future secure connections originating from the SMS on vCenter Server and on ESXi hosts.