Admins routinely use semi-secure self-signed SSL certificates in their VMware environments. But with the trend...
toward tighter security settings in View 5.1 – and most recently VMware PowerCLI – the writing is on the wall: Admins must reconsider their approach or potentially face problems.
More resources on VMware PowerCLI
Even though self-signed certificates are not fully trusted, they match the name of the server and have a thumbprint that confirms the identity of the server. VMware admins accept the default self-signed security certificates, reasoning that the service isn’t for end users and it’s on a trusted network, so why bother about the cost and hassle of creating and managing fully-trusted certificates?
VMware admins know that the vendor’s tools default to using secure protocols such as Secure Sockets Layer (SSL) on port 443 and elsewhere for communications. Even on vCenter, where port 80 is open, Web communications all redirect to a fully secured 443 SSL connection.
VCenter and the vSphere Client also use security certificates that are auto-generated during the installation, and admins treat these vCenter certificates like they treat certificates for appliances and ILO (HP)/DRAC (Dell) cards.
Fig.1: Most VMware admins accept the untrusted SSL certificate, opting to install the auto-generated certificate to prevent the warning in future.
Tighter security in View 5.1
Only for VMware’s virtual desktop product, View, do admins use a fully-trusted and secure certificates. This is because end users use View, and IT wants to avoid end users ask them on whether they can trust the service each time they see the warning pop up.
Here is more information about how users can install and manage the stringent SSL certificates in View’s 4.5 and 5 versions.
VMware View 5.1 introduces an even more stringent approach to SSL certificates than previous versions.
Admins can still use untrusted self-signed certificates. But, if they do, they’ll find areas where this approach brings problems.
First of all, an untrusted connection server and security servers now generate an “alarm” condition in the new “dashboard” view for the product.
Fig.2: Here the “red” alarms on the Connection Servers (CS01/CS02) and the Security Server (SS01/SS02) indicate an invalid certificate is in use. You might notice that there are green alarms on the vCenter and View Composer components. These would normally be in red by default. However it is possible “verify” the self-signed auto-generated certificates for these services. That’s not the case for the Security Server or the Connection Server alarms. For those you must have a valid certificate that either matches the servers FQDN or the “External URL” of the View infrastructure.
In addition, the new Windows-based View Client now has options to configure settings that control how it handles invalid certificates. By default, the option is to allow connections to connect if a certificate is invalid, but to warn the end-user of this fact.
Fig.3: By default, the new Windows View Client use “Warn if the connection may be insure” is selected. In this screen grab I selected the more rigorous “Reject the unverifiable connection” option.
The default warning setting is similar to what users are familiar with in common Web browsers such as Internet Explorer.
Fig.4: Users will be familiar with the standard Internet Explorer warnings
If the administrator changes the View Client’s SSL defaults like I have done in Fig.3, then the certificate must match the name of the server to which the user is connecting, or the connection will be refused.
Some third-party VDI brokers with which VMware View competes with already enforce this level of security by default.
In contrast, the View Client still allows the end-user to ignore the warnings and connect directly to untrusted system -- leaving them potentially vulnerable to the man-in-the-middle exploits. All of which makes me wonder if VMware will tighten the screws further in its next version of View?
Stringent security spreading to VMware PowerCLI?
View isn’t the only VMware product that encourages the use of fully trusted certificates. VMware PowerCLI also comes with new security controls that stem from its use of SSL to connect to vCenter in order to carry out command-line administration.
I recently installed VMware PowerCLI (5.0.1) and was taken aback by the message that appeared when I tried to connect to the vCenter server for the first time:
Fig.5:The surprise warning message while installing the latest version of VMware PowerCLI
For me, the most important part of this was the warning text at the bottom in capital letters:
“WARNING: THE DEFAULT BEHAVIOR UPON INVALID SERVER CERTIFICATE WILL CHANGE IN A FUTURE RELEASE.”
The VMware PowerCLI warning continued: “To ensure scripts are not affected by the change, use Set-PowerCLIConfiguration to set a value for the InvalidCertificateAction option.”
It’s not quite clear what the change in default behaviour might be, but I suspect that in future version of PowerCLI, VMware could refuse connections to an untrusted vCenter server unless the administrator explicit lowers the security with the “Set-PowerCLIConfiguration” cmdlet.
Alternatively, VMware may decide to change the configuration to warn the administrator of insecure connection, and wait for the administrator to deny it, accept it once, or accept it permanently.
If that happens, a VMware PowerCLI script that works with vCenter non-interactively might stall while it waits for a human operator to agree to the unsecured connections.
All this sounds rather scary, but if you think about it, the defaults in VMware PowerCLI are merely being aligned with vSphere Client’s. In vSphere Client, non-secure connections are allowed and admins can permanently supress the warning by selecting “ignore”.
To suppress this warning on VMware PowerCLI run this cmdlet:
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm: $false
The way forward?
This change in VMware PowerCLI is effective immediately and VMware is enforcing it as a global setting.
As of right now you don’t need to have a valid certificate for VMware PowerCLI communications, and if VMware changes this, you will likely still be able to set the invalid certificate action and ignore any warnings.
But this raises some questions. Is this VMware’s new policy for all its products? If so, what brought about this change? Have there been some changes from FIPS that have triggered these sorts of security enhancements? From what I know, there’s no specific project or policy that brought these changes to VMware PowerCLI.
It could be part of VMware’s on-going process of incorporating security best practices into its products based on customer feedback. Like it or hate it, virtualisation admins should not ignore VMware tightening security screws in VMware PowerCLI and View 5.1.
Mike Laverick is a former VMware instructor with 17 years of experience in technologies such as Novell, Windows, Citrix and VMware. Since 2003, he has been involved with the VMware community. Laverick is a VMware forum moderator and member of the London VMware User Group. He is also the man behind the virtualisation website and blog RTFM Education, where he publishes free guides and utilities for VMware customers. Laverick received the VMware vExpert award in 2009, 2010 and 2011.
Since joining TechTarget as a contributor, Laverick has also found the time to run a weekly podcast called the Chinwag and the Vendorwag. He helped found the Irish and Scottish VMware user groups and now speaks regularly at larger regional events organised by the global VMware user group in North America, EMEA and APAC. Laverick published books on VMware Virtual Infrastructure 3, vSphere4, Site Recovery Manager and View.