A few months ago we had an issue logged in PowervRA where it was not possible to make a connection to the vRA appliance after it had been locked down following the VMware hardening guide. Specifically this was because SSLv3/TLSv1 (weak ciphers) had been disabled.
By default, Windows PowerShell 5.1 has the following Security Protocols available, Ssl3 and Tls – hence the above failure.
It’s possible to workaround this by adding in the security protocol required, in this case TLS 1.2
Note, however, that this change is for the PowerShell session itself, which may or may not be desired behaviour.
PowerShell Core adds in a new parameter SslProtocol to both of the web cmdlets, Invoke-WebRequest and Invoke-RestMethod. Consequently, this improvement means that you can specify a security protocol per request, not per PowerShell session. For example you could do something like this for Tls 1.2:
In PowervRA 3.0.0 we’ve updated Connect-vRAServer to support this functionality, also with a SslProtocol parameter:
If you’re on Windows PowerShell we’ll add to the available security protocols in the PowerShell session (and remove it afterwards when you use Disconnect-vRAServer). If you’re using PowerShell Core we’ll use the SslProtocol parameter of Invoke-RestMethod so that the requested protocol is used per request.
The $vRAConnection variable has been updated with the SslProtocol property to show you whether your connection is using the default protocol or a specified one:
Final note: this was a breaking change for us, since we require Windows PowerShell 5.1 and PowerShell Core 6 release candidate to easily implement the above functionality. So make sure you are on either of those versions before trying PowervRA 3.0.0.