Security is an important factor within your vSphere Infrastructure. This is why all traffic between the vCenter server and the ESXi hosts is encrypted using Transport Layer Security (TLS). ESXi support TLS by the use of SSL version 3 or TLS version 1 type certificates, generally referred to as SSL certificates. For more information on data encryption see Transport Layer Security on Wikipedia.
The use of SSL certificates within ESXi
SSL certificates are used within vSphere by default. Both vCenter and ESXi create their own SSL certificates during the installation process.During the creation a certificate and a private key are generated and are stored in the following location :
- SSL certificate => /etc/vmware/ssl/rui.crt
- SSL private key => /etc/vmware/ssl/rui.key
Both these keys are used to encrypt the data communication between the ESXi host and the vCenter client. And between the ESXi host and the vSphere client. This can be noticed when connect to either the vCenter server or ESXi host with a vSphere client. A warning message is then shown that the certificated used by the vCenter server or ESXi host could not be verified. Simply ignoring this will notice or installing the certificate on your local host will resolve this warning message.
To summarize : ESXi by default uses data communication encryption with self-generated SSL certificates.
Replacing the default SSL certificates ESXi
The ESXi default certificates that are created during the installation process are unique. However these certificates aren’t verifiable and aren’t checked against a central certificate authority (CA) that is known and trusted within the IT infrastructure.
Some companies require the use of a company CA server to validate the SSL certificates. Most commonly used is the Microsoft Active Directory Certificates server that validated certificates in a Public Key Infrastructure (PKI). You will need to generate your new SSL certificates for ESXi that are signed by the CA. After generating the new certificate and private key for the ESXi host(s) that have been signed by the CA the files need to be uploaded to your ESXi host.
The ESXi Configuration Guide presents you with two ways to upload the files to your ESXi host :
Via the vSphere CLI :
vifs –server <hostname> –username <username> –put rui.crt /host/ssl_cert
vifs –server <hostname> –username <username> –put rui.key /host/ssl_key
Upload your files via the HTTPS PUT command to the following sites :
For SSL certificates : https://<hostname>/host/ssl_crt
For keys : https://<hostname>/host/ssl_key
The last can be achieved by using a program that is able to execute a HTTPS PUT command.
Powershell
To be able to upload the certificate and private key file I’ve created a script that is able to upload the SSL certificate and private key using the HTTPS PUT command and Powershell. The script can be downloaded via VMware DOC 14655.
But does certificate stay in ESXi even after reboot?
The script replaces the rui.key and rui.crt which are located in the directory /etc/vmware/ssl. After a reboot ESXi will use these files for encryption. So the answer to your question is yes.
Regards,
Martijn
The certificate file will not be preserved if you reboot the ESXi server too quickly after replacing the original. ESXi runs in memory (RAM disk), certain files that need to be persistent are copied to the equivalent of an initrd file on persistent storage at regular intervals. This is done by a script called auto-backup.sh which runs on the first minute of every hour.
If you reboot before the script has been run, you will lose any changed files.
Nice piece of information John! Thanks.
Didn’t hit any issues yet while using my PowerCLI script. Then again I didn’t reboot the server that fast after executing the script. Something to investigate 😀
Investigated what happens in case of a imidiate reboot after a certificate file replacement and didn’t verify that the certificate file is being set back to the “old” certificate file.
I presume that in case you initiate a reboot the auto-backup.sh is kicked of before rebooting the server. That saves the state of the configuration files to state.tgz in the /bootbank directory. This directory containt the ESXi hypervisor code and configuration.
Actually, I need to correct myself – if the reboot is controlled the config should be saved. If the server loses power or has a hard reset the config might be lost.
I thought I would mention in ESXi 4.1, the SSL keys are not actually stored in /etc/vmware/ssl/. While there is such a directory, it is my impression the 2 hidden files in that folder (.#rui.crt and .#rui.key) are only logical representations of the actual keys, which I suppose are buried away in a keystore somewhere. You will also notice the vifs –put location (/host/ssl_cert) appears to be logical as well.
I ran into this when I broke a test instance of ESXi (running in vmplayer thankfully) by inadvertently uploading an rui.crt in the p7b format. So I thought I could just use opensll to convert the certificate to the correct PKCS # 12 PEM format right there on the ESXi host itself….well there may be a way to do that, but I have not discovered it yet. And VMware isn’t telling.
Uploading keys is a one shot deal because the upload occurs over SSL. If you break SSL, there is no way to upload a replacement key. The only way out of such a situation may be to regenerate self signed keys on the ESXi host itself. This would at least give you a chance to try it again.
Hi,
As far as I know /etc/vmware/ssl is the location where the rui.key and rui.crt are stored per ESXi host. I’ve had several clients that have ESXi hosts running certificates from there internal root CA. All of them have either been replaced with the PowerCLI script or a kickstart file that copies the company certificates to the directory and writes over the rui.key and rui.crt in the directory /etc/vmware/ssl.
The location /host/ssl_cert and /host/ssl_key refer to the web interface on the ESXi host (go to https:///host). They link to the files in /etc/vmware/ssl
Regards,
Martijn