VMware: Data Security Best Practices – SSL keys for communicating with VirtualCenter and other applications (1008166)

1

SSL keys are used in the communication between ESX Server, VMware Server, and VMware ACE on one side and management applications like VirtualCenter on the other side. VMware recommends that you follow industry best practices regarding data security and establish protocols for periodically replacing or regenerating your SSL keys in order to improve the data security of your systems.

This article contains the following topics:

  • Regenerating or Replacing SSL Certificates
  • Best Practices for Sending Support Data to VMware
  • vm-support Script Update

Regenerating or Replacing SSL Certificates

The SSL keys on ESX Server, VMware Server and VMware ACE are generated during the installation of these products. These keys are used to set up communication using the SSL protocol.

Following industry best practices, VMware recommends that you regenerate the SSL keys on ESX Server, VMware Server, and VMware ACE according to your company’s security policy. In the case of custom certificates, replace these certificates according to your company’s security policy.

To regenerate certificates

  • For ESX Server 3i version 3.5: See the section "Encryption and Security Certificates for ESX Server 3i" in the ESX Server 3i Configuration Guide on page 179.
  • For ESX Server 3.5: See “Encryption and Security Certificates for ESX Server 3” in the ESX Server 3 Configuration Guide, page 231.
  • For ESX Server 3.0.x: See "Regenerating Certificates" in the Server Configuration Guide, page 232.
  • For ESX Server 2.5.5, and VMware Server 1.0.x and 2.0: SSL certificates for these products cannot be regenerated automatically. Create a self-signed certificate and replace the existing certificate by the newly created certificate. This process is described in "Creating Self-signed Certificates" in Replacing VirtualCenter Server Certificates.

To replace certificates

Note: Regenerating or replacing certificates as referenced above in combination with using the non-default Certificate Checking option in VirtualCenter requires these additional steps:

  1. Reboot the ESX host or VMware Server after changing certificates.
  2. Reset the password of the VirtualCenter database (this password is randomly generated) as follows:
    1. On the system where VirtualCenter is installed, enter the following commands on the command-line interface:
      cd C:\Program Files\VMware\Infrastructure\VirtualCenter Server\
      vpxd –p
  3. Exit VI Client.
  4. Restart the VirtualCenter service.
  5. Restart the VI Client.

Note: For environments that require strong security, VMware recommends that administrators replace all default self-signed certificates generated at installation time with legitimate certificates signed by their local root certificate authority or public, third-party certificates available from public certificate authorities. For more information, see the Security Hardening Guide – VMware Virtual Infrastructure 3.

Best Practices Regarding Sending Data to VMware

As a reminder, VMware advises to discard the output of the vm-support script after it has been provided to VMware support or its partner support.

vm-support Script Update

During a recent security review, VMware found that SSL keys collected along with other support data do not provide value in the support process. In order to improve our processes, VMware has decided to discontinue collecting the SSL keys and accordingly requires users to use the updated vm-support script whenever they are using the vm-support script. This is only relevant for ESX Server and VMware Server. No SSL keys have been collected for other VMware products, including VMware ACE.

The script that collects the data for support, vm-support, is only run by administrators and is never run automatically. A typical scenario where support might ask the administrator to run the script is when support needs to review configuration data from an ESX Server or VMware Server installation. In this scenario, the administrator runs the script and provides the output to support.

In case you are requested to run the vm-support script by support, or if you are using the vm-support script in any other way, you will need to replace your current script with the updated version. This can be done in the following two ways.

Update the vm-support script manually

  • For ESX Server 3i version 3.5: The vm-support script cannot be manually installed on ESX Server 3i hosts. These hosts must be patched in order to replace the script.
  • For the following versions of ESX Server–3.5, 3.0.x, 2.5.5: See "To install a new version of vm-support, if you have an older version" in Collecting diagnostic information for VMware ESX Server (KB 653).
  • For VMware Server 1.0.x and 2.0: See "To install a new version of vm-support, if you have an older version" in Collecting diagnostic information for VMware Server (KB 1008254).

Deploy the patch with the updated vm-support script on ESX Server or install the new version of VMware Server

Note: ESX Server patches that contain the VMware-esx-scripts RPM that are released after the ESX Server patches mentioned above will also contain the update to the vm-support script.

Customers who have concerns that someone might have had access to the output of the vm-support script are advised to regenerate or replace their SSL keys (see the KB articles mentioned above for details). The vm-support script is only run on demand and the vm-support script will never generate output on its own.

Check out the complete knowledge base article after the jump

Source: 1008166

About Author

1 thought on “VMware: Data Security Best Practices – SSL keys for communicating with VirtualCenter and other applications (1008166)

Leave a Reply

Your email address will not be published. Required fields are marked *