The state of SSL/TLS on vSphere is quite a mess, I guess your audit only tested port 443, but there are a lot of other ports in a vSphere ecosystem that run SSL/TLS. As a primer before what I I'm going to explain check this earlier post:
I have my doubts about the nature of your audit, they are suggesting changes that will not only likely impact your environment, but many of them are completely out of place, outdated or even counter-from a security standpoint:
TLS Server Supports TLS version 1.0
TLS Server Supports TLS version 1.1
Yes, TLS 1.2 (and soon 1.3) is the best choice, but forcing 1.2 is just asking for trouble and I haven't heard of any serious security claim that 1.0 or 1.1 are insecure, unlike SSL 3.0.
Guessworking from this KB it seems like you might be able to disable TLS 1.0 and 1.1 on ESXi port 443 with:
esxcli system settings advanced set -o /UserVars/ESXiHostdDisabledProtocols -s "SSLv3 -TLSv1 -TLSv1.1"
Even if it works it will most likely be not supported.
TLS/SSL Server Does Not Support Any Strong Cipher Algorithms
TLS/SSL Server Supports 3DES Cipher Suite
TLS/SSL Server Supports The Use of Static Key Ciphers
I would need a detailed definition of what your audit considers "Strong", but as a matter of fact ESXi 5.5 U3 on port 443 supports TLS_RSA_WITH_AES_256_CBC_SHA.
AES256 is far from insecure, but this suite lacks forward secrecy which might be the reason its not considered strong. The lack of a forward secrecy cipher suite is also causing the "Static Key Ciphers" warning.
3DES is considered deprecated but there are no known (practical) attacks yet. I'm not sure where this is coming from because ESXi 5.5 U3 and vCenter 5.5 U3 do not support 3DES, at least on port 443.
I'm not aware of any supported or unsupported method to change the cipher suite selection on ESXi.
TLS/SSL Server is enabling the BEAST attack
BEAST is an outdated thing no security guy who takes himself seriously cares about anymore. On TLS 1.0 the only way to defend against BEAST is to force RC4 only - which is commonly considered more insecure than BEAST, which is a really impractical attack and mitigated client-side since years. Essentially you would need to disable TLS 1.0 and and force GCM-only cipher suite available since TLS 1.2 to defend against BEAST.
Untrusted TLS/SSL server X.509 certificate
This is probably the only point you can amend on more or less clean, supported ways by implementing your own CA-signed certificates instead of relying on the VMware default ones. You could even be doing that already and it's just that the auditor did not have your own root CA certificate if you have your own CA.
What your auditor missed though is that ESXi is still vulnerable against client-initiated TLS renegotiation DoS.
I suggest you take a look at the VMware security hardening guides here, though they aren't really going into detail in terms of TLS/SSL:
I will sift through the links; thank you very much for the information and addition posts, especially the hardening guide! I have to say, much more helpful than anything I've encountered by Googling or calling into VMware support itself.
Also see how you can mitigate everything by putting all the vSphere Mgmt bits behind a firewall using Jump Machines to access. If the TLS/SSL bits are not publically available you may be able to mitigate items quite easily within an audit. This is really the best practice for all management bits for vSphere. The hardening guide is GREAT and should be used properly but look at other means of mitigating the larger issues. No one should be able to hop from their desktop direct to the vCenter client IMHO.
Edward L. Haletky
VMware Communities User Moderator, VMware vExpert 2009-2016
Author of the books 'VMWare ESX and ESXi in the Enterprise: Planning Deployment Virtualization Servers', Copyright 2011 Pearson Education. 'VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment', Copyright 2009 Pearson Education.