By default, VMware uses self-signed SSL certificates to establish a secure connection between a client and server, but some organizations may find that the default SSL certificates are not secure enough.
More on VMware SSL certificates
Certificates and the VMware Infrastructure 3 SDK
Creating and applying certificates in
The default, self-signed SSL certificates are fine, as long as communication remains within a private network. However, any time traffic is sent across the Internet – which may occur when establishing a remote-management session with a vSphere infrastructure – it is better to use certificates signed by a trusted third party, which will verify the identity of your server.
Secure Sockets Layer (SSL) is a protocol that allows organizations to securely pass information between servers and clients. SSL uses a public/private key pair to encrypt data on the wire and to guarantee the identity of the server that you are communicating with.
When a user’s computer makes contact with a server, the server will send its public key infrastructure (PKI) certificate file. In the case of a signed certificate, a third party, known as a certificate authority, certifies that the certificate is authentic. However, these certificate costs money, and that´s why VMware uses self-signed SSL certificates by default.
Using a self-signed SSL certificate still ensures that the data is encrypted, but users cannot confirm that they are connecting to your server. Most Web browsers will notify a user if a secure connection is not signed by a certificate authority, flagging the connection as potentially dangerous. You can see this the first time you use the vSphere Client to connect to the ESXi host, which displays a message that the identity of your host cannot be verified.
Replacing self-signed SSL certificates
In most cases, your host is in your data center, so verifying its identity isn’t that important. In an environment that requires an increased level of security, you can replace the self-signed SSL certificate with a certificate generated by an external, trusted authority. Many organizations require certificates from third-party authorities to remain compliant with current regulations. You can request signed certificates from a certificate authorities, such as Thawte, Verisign or CACert.
The external certificate authority will send two files: One file with the extension .key, and another with the extension .crt. The .key file is the private key for your ESXi host, and you should protect access to it. The .crt file is the PKI certificate, which is sent to the client when the connection is initiated. This file is offered to the user who wants to connect with your server. You should make sure to copy these files to your ESXi server.
To copy the files to your ESXi host, you need to use the vCLI interface. You can download the vCLI installer for free from the VMware website. After you download the vCLI interface, open a command shell in Windows, and use the cd command to activate the vCLI folder (c:\Program Files\VMware\VMware vSphere CLI\bin by default). You can now copy the .key and .crt files to the correct location on the ESXi host using the commands below.
vifs --server youresxiserver.example.com --put yourkey.key /host/ssl_key
vifs --server youresxiserver.example.com --put yourkey.crt /host/ssl_cert
These commands assume that the files are in your current directory, so make sure to adjust the code to refer to the directory where you have downloaded these files. After copying over the files, restart the management interface to use them immediately.
Replacing self-signed SSL certificates on the ESXi host isn’t difficult and may give users an added sense of security when connecting to your server. But, first, you must weigh the cost of using a certificate authority, if regulations pertaining to your organization don’t prohibit self-signed SSL certificates.