The VMware vSphere 8 Default SSL/TLS Cipher Suites have recieved an update from the vSphere 7 defaults and got rid of some legacy stuff. Still, there might be a compliance requirement to even reduce this list.

The goal of this post is to get rid of everything that is SHA1 based (e.g. AES256-SHA) on the vCenter Appliance. At the time of writing, the post was confirmed working for vSphere 8.0 Update 1 - further updates may introduce changes that are not reflected in the post unless they are specifically marked as updated.

*** DISCLAIMER ***

Doing it on your own is not supported by VMware.

As stated on the cipher overview:

Activating and deactivating particular ciphers is beyond the scope of this document and not recommended except under the direct guidance of VMware Global Support Services. Changes made by customers to cipher suites are not tested by VMware, may cause incompatibilities and system malfunctions, and may be inaccessible or overwritten during patching or updates

The vCenter contains a ton of service and there is no single configuration file for ALL the services, so we need to change them one by one.

As a general note, SSL ciphers are specified as list of individual ciphers or groups of ciphers, separated by a “:” and optionally an operator. The operator mostly used is “!”, which disables a cipher.

We aim leave the defaults as they are and just add the ciphers we do not want to the list. This way, we can handle future changes for the defaults but ensure our desired state is still met. In most cases we can use the shorthand “:!SHA1”.

The manual testing of all the services and ciphers after a change is quite cumbersome. Therefore I wrote a small bash-script to do the checks and just report on the supported ciphers. You can find it on my github script-junkyard.

Since we’re doing unsupported stuff anyway, the script was designed to be executed directly on my lab vCenter but can be used for remote checks by changing the hostname/IP.

Here is a sample of the expected output:

Connecting to 127.0.0.1
Testing on port 443
SUCCESS: ECDHE-RSA-AES256-GCM-SHA384
SUCCESS: ECDHE-RSA-AES256-SHA
SUCCESS: AES256-GCM-SHA384
SUCCESS: AES256-SHA
SUCCESS: ECDHE-RSA-AES128-GCM-SHA256
SUCCESS: ECDHE-RSA-AES128-SHA
SUCCESS: AES128-GCM-SHA256
SUCCESS: AES128-SHA
---
Testing on port 636
SUCCESS: ECDHE-RSA-AES256-GCM-SHA384
SUCCESS: ECDHE-RSA-AES256-SHA384

[output truncated for brevity]]

If you are still doing this while being on unsupported territory, please have at least a backup of your vCenter and all files you are going to change.

RHTTPPROXY-based services (port TCP/443, TCP/8084, TCP/9087)#

The rhttpproxy config pushes out the changes to the backend (i.e. envoy) and will use default values unless otherwise specified.

This means, we need to add the desired state to the configuration file /etc/vmware-rhttpproxy/config.xml. By default there is an commented example for “cipherList” in the ssl section below config - vmacore.
We leave it unchanged and add a new entry on line 159 of /etc/vmware-rhttpproxy/config.xml:

<cipherList>ECDHE+AESGCM:RSA+AESGCM:ECDHE+AES:RSA+AES:!SHA1</cipherList>

Restart the service with vmon-cli -r rhttpproxy and check the results.
The expected output is:

Connecting to 127.0.0.1
Testing on port 443
SUCCESS: ECDHE-RSA-AES256-GCM-SHA384
SUCCESS: AES256-GCM-SHA384
SUCCESS: ECDHE-RSA-AES128-GCM-SHA256
SUCCESS: AES128-GCM-SHA256
---
[output truncated for brevity]]

Make sure to check your SPS service and I/O provider connections after this change

Sidenote about rhttpproxy-behavior#

I found that rhttpproxy will accept basically anthing in the configuration file without notice but will refuse to push the change in the backend. As an example I added “!cheesecheese” to the cipers list:

   <cipherList>!cheesecheese:ECDHE+AESGCM:RSA+AESGCM:ECDHE+AES:RSA+AES:!SHA1</cipherList>

and found that rhttp will accept it

root@vcenter-1 [ /etc/vmware-rhttpproxy ]# vmon-cli -r rhttpproxy
Completed Restart service request.

But in case you encounter problems, take a look at /var/log/vmware/rhttpproxy/rhttpproxy.log to find the culprit:

2023-09-21T14:09:36.959Z error rhttpproxy[28341] [Originator@6876 sub=EnvoyAds] Envoy rejected update. Error code: 13, message: Error adding/updating cluster(s) remote-plugin-cluster-com.vmware.vsan.client-8.0.201.10000-585663107-XXX-443: Failed to initialize cipher suites !cheesecheese:ECDHE+AESGCM:RSA+AESGCM:ECDHE+AES:RSA+AES:!SHA1. The following ciphers were rejected when tried individually: cheesecheese,

VAMI (port TCP/5480)#

For the vCenter Server Appliance Management Interface (VAMI) we have default settings in place which need to be adjusted.

Open the file /etc/applmgmt/appliance/lighttpd.conf and replace the cipher-list (around line 16) with this:

ssl.cipher-list = "!aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES:!SHA1"

Restart the service using service vami-lighttp restart and check the results.

The expected output is:

Testing on port 5480
SUCCESS: ECDHE-RSA-AES256-GCM-SHA384
SUCCESS: ECDHE-RSA-AES128-GCM-SHA256
SUCCESS: ECDHE-RSA-AES256-SHA384
SUCCESS: ECDHE-RSA-AES128-SHA256
SUCCESS: AES256-GCM-SHA384
SUCCESS: AES128-GCM-SHA256
SUCCESS: AES256-SHA256
SUCCESS: AES128-SHA256

Platform Service Controller (port TCP/636)#

The Platform Service Controller (PSC) is serving on port 636 for any vCenter Server Enhanced Linked Mode connection.

PSC uses defaults unless otherwise configured. For a change, we don’t adjust configuration files but need to adjust configuration with lwregshell similar to a Windows registry.

Getting here with minimal steps:

/opt/likewise/bin/lwregshell add_value '[HKEY_THIS_MACHINE\Services\vmdir\Parameters]' "SslCipherSuite" "REG_SZ" 'ECDHE+AESGCM:RSA+AESGCM:ECDHE+AES:RSA+AES:!SHA1'

#Verification
/opt/likewise/bin/lwregshell list_values '[HKEY_THIS_MACHINE\Services\vmdir\Parameters]'

Restart the service using service-control --stop vmdird && service-control --start vmdird and check the results.

The expected output is:

Testing on port 636
SUCCESS: ECDHE-RSA-AES256-GCM-SHA384
SUCCESS: ECDHE-RSA-AES256-SHA384
SUCCESS: AES256-GCM-SHA384
SUCCESS: AES256-SHA256
SUCCESS: ECDHE-RSA-AES128-GCM-SHA256
SUCCESS: ECDHE-RSA-AES128-SHA256
SUCCESS: AES128-GCM-SHA256
SUCCESS: AES128-SHA256

vSphere Pod Service for vSphere with Tanzu (port TCP/5580)#

The Workload control plane a.k.a. vSphere Pod Service for vSphere with Tanzu is running the twistd service on port 5580.

We need to adjust the configuration file /usr/lib/vmware-pod/bin/pod-twistd by appending the SHA1 deny

VMW_CIPHERS = '!aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES:!SHA1'

The service must be restarted with service vmware-pod restart, but beware this takes a while.

The expected output is:

Testing on port 5580
SUCCESS: ECDHE-RSA-AES256-GCM-SHA384
SUCCESS: ECDHE-RSA-AES256-SHA384
SUCCESS: AES256-GCM-SHA384
SUCCESS: AES256-SHA256
SUCCESS: ECDHE-RSA-AES128-GCM-SHA256
SUCCESS: ECDHE-RSA-AES128-SHA256
SUCCESS: AES128-GCM-SHA256
SUCCESS: AES128-SHA256