Introducing the strong security mode
Overview
VMware is always striving to provide the customers with stable and secure instruments for virtual infrastructure management. To achieve this goal we aim to comply with the established industry standards, especially in the context of trusted communication.
With an upcoming major release of vSphere, we will introduce the strong security mode for the vCenter, reflecting the security posture VMware recommends to our partners and customers to apply in their infrastructure mgmt. operations. The strong mode does not support SHA-1 as a cryptographic hash function. We recommend to replace it with the supported and more secure SHA-256. The strong mode also supports full SSL certificates as trust exchange mechanism, which may impact some vSphere APIs using certificate thumbprints as arguments, or as part of the API response. Such APIs may not be supported when the strong mode is switched on.
In parallel with the strong mode, a compatible security mode will still be supported for the purpose of backward compatibility. The compatible mode still supports SHA-1 as a cryptographic hash function, and it relies on the SSL certificate thumbprints as a valid source of trust. Using the compatible mode will not be recommended. The switch between the modes will be done through a property of the vCenter Server Appliance. Detailed information will be provided in the documentation of relevant vSphere release.
Upgrade
Starting from the said upcoming major release, all greenfield deployments of vCenter instances will be configured with the strong mode enabled by default. All partner solutions relying on the legacy cryptographic hash algorithms, such as SHA-1 or MD5, will be impacted. The customers will have the option to switch to the compatible mode, but it will be considered in deprecated state and not recommended by VMware.
The brownfield vCenter instances upgraded to the major version in question will continue operating with the compatible mode enabled by default, unless the customer has switched to the strong mode prior to updating the vCenter. Considering the recommendation from VMware, the inherent risks and the ongoing industry trends, we expect our customers to apply the most strict security settings available. This change will impact vSphere Client plugins relying on SHA-1 when registering with the vSphere Extension manager. Failing to adapt to the requirements of the vCenter security strong mode will carry the risk for relevant vSphere Client plugin to become unusable.
Impact on vSphere Client plugins
Transition from SHA-1 to SHA-256
All VMware partners must be aware that, starting from upcoming major release, vSphere Client plugins relying on the legacy SHA-1 standard, will not be supported when vSphere security strong mode is enabled in the customer infrastructure environment. To resolve this problem and ensure the compatibility of their solution, VMware strongly advises our partners to make sure the next versions of the vSphere Client plugins they offer support SHA-256 as encryption algorithm.
The SHA-1 algorithm has been in deprecated state since the general availability release of vSphere 7.0U1. We have provided the capability for vSphere Client plugins to register to the Extension manager using SHA-256 as hashing algorithm with the release of vSphere 7.0U3. As the next step in this process, for the upcoming major release of vSphere, the plugins need to abandon the use of the SHA-1 as a cryptographic hash function.
Transition from certificate thumbprints to full SSL certificates
Together with the migration from SHA-1, vSphere Client extensibility is gradually transitioning to the use of full SSL certificates for plugin registration. The full certificate support was introduced for the Client SDK with the release of vSphere 8.0U2. Performing a full SSL certificate check during SSL handshake is more secure than performing a SSL certificate thumbprint check, even if the plugin already uses а SHA-256 SSL certificate thumbprint.
To ensure forward and backward compatibility of plugins, we recommend to our partners, for the time being, to provide their solutions with the capability to register with vSphere Client Extension manager using both a certificate and a thumbprint. That would be necessary because, in some environments, there could be vCenter instances, which don’t support certificates, that may try to load a newer plugin version which is only registered with a certificate.
For example, they could apply certificate thumbprint (using SHA-256 as hash algorithm) for registration with vCenter running on version 8.0U1 or earlier, and full SSL certificate for vCenter 8.0U2 or later.
Local plugins end of life
We want to remind all our partners and customers that all vSphere Client plugins relying on the legacy local plugin architecture will not be supported starting from the next major release of vSphere. The local plugins have been deprecated with the GA release of vSphere 8.0. The support of local plugins ends with the next major vSphere release.
All VMware partners need to provide their customers with a plugin version based on the remote plugin architecture to enable them to continue using the partner solution with the next major release of vSphere.
Transition to TLS 1.3
Starting with the upcoming update release of vSphere, we will provide support for the Transport Layer Security protocol version 1.3, together with the legacy TLS 1.2, which is enabled by default. In the next major release, TLS 1.2 and TLS 1.3 will be co-existing and the default vCenter configuration will support both versions of the protocol. However, with the said major release we will introduce a configurable mode of vCenter which supports only TLS 1.3. Our intent is to deprecate TLS 1.2 and stop supporting it from the subsequent major release.
We strongly recommend to our partners to consider adding support for TLS 1.3 in their plugin solutions so that these solutions operate normally in all vCenter configurations.
