New ESXi installation findings in Nessus

While running a vulnerability scan against a new system, that I am building for a colo I had Nessus pick these on a brand new ESXi install.

SSL Certificate Cannot Be Trusted

The self-signed certificates are a real nightmare in implementing a successful security programme as they form bad habits (“I will accept that certificate without thinking, and then any other that I come across”) among our user base, and as such should be replaced with properly signed certificates before the service/application reaches the production stage.

Anyway, the procedure below describes the steps needed to replace the self-signed certificates that came with the ESXi with your own.

Firstly, generate a proper CSR with the below command:

openssl req \
-new \
-newkey rsa:4096 \
-days 3650 \
-nodes \
-subj "/C=AQ/ST=Antarctica/L=South Pole/O=mikenowak.org/CN=esxi1.mikenowak.org" \
-reqexts SAN \
-config <(cat /etc/ssl/openssl.cnf \
<(printf "[SAN]\nsubjectAltName='DNS:esxi1.mikenowak.org'")) \
-keyout ${1}.key \
-out ${1}.csr

The reason I stress *proper* above is that the CSRs generated from within the ESXi UI (at the time of writing this post) lack the SAN (subjectAltName) attribute.

Now, starting with version 58 Chrome had deprecated CN subject matching, and certificates without a valid SAN are rejected with NET::ERR_CERT_COMMON_NAME_INVALID, like in the screenshot below.

Now have that CSR signed by your Corporate CA or some other CA trusted by your clients.

With both key and signed certificate at hand we can now install these on the ESXi server in the following locations:

* Key: /etc/vmware/ssl/rui.key
* Certificate: /etc/vmware/ssl/rui.crt

NB: It is also a good idea to add your Corporate CA Certificate to /etc/vmware/ssl/castore.pem if you’re planning on shipping syslog from ESXi to Splunk over TCP+SSL.

Save the changes by running auto-backup.sh

Finally, run /etc/init.d/rhttpproxy restart to restart the rhttpproxy service.

SSH Server CBC Mode Ciphers Enabled

So for reference the solution is pretty simple and boils down to changing the ciphers and algorithms in the /etc/ssh/sshd_config, as follows

replace

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1

with

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Now run the auto-backup.sh to save the change and restart sshd.

I also highly recommend checking Mozilla’s OpenSSH Security Guideline.

Good luck!