PowerCLI v11.3.0.13990089 InvalidCertificateAction not Working...

[edgerch]

In the last version of the PowerCLI (v11.3.0.13990089) the "InvalidCertificateAction" setting is ignored by Connect-VIServer command.

I've executed the following command:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false -ProxyPolicy NoProxy -ParticipateInCeip $false -DisplayDeprecationWarnings:$true -DefaultVIServerMode Multiple;

With the result:

Scope	ProxyPolicy	DefaultVIServerMode	InvalidCertificateAction	DisplayDeprecationWarnings	WebOperationTimeout
					Seconds
-----	-----------	-------------------	------------------------	--------------------------	-------------------
Session	NoProxy	Multiple	Ignore	True	300
User	NoProxy	Multiple	Ignore	True
AllUsers	NoProxy	Multiple	Ignore	True

Howeber, when I execute the command:

Connect-VIServer -Server <somehost> -Verbose;

I get this error:

DETALLADO: Attempting to connect using SSPI

DETALLADO: No se pudo establecer un canal seguro para SSL/TLS con la autoridad '<somehost>'.

DETALLADO: Connect using SSPI was unsuccessful

DETALLADO: No se pudo establecer un canal seguro para SSL/TLS con la autoridad '<somehost>'.

Connect-VIServer : 04/07/2019 07:09:24 PM       Connect-VIServer                Error: Invalid server certificate. Use

Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you'd like to connect

once or to add a permanent exception for this server.

Additional Information: No se pudo establecer un canal seguro para SSL/TLS con la autoridad '<somehost>'.

En línea: 1 Carácter: 1

+ Connect-VIServer -Server <somehost> -Verbose;

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : SecurityError: (:) [Connect-VIServer], ViSecurityNegotiationException

    + FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_CertificateError,VMware.VimAutomation.ViCore.

   Cmdlets.Commands.ConnectVIServer

Apparently, the "-InvalidCertificateAction Ignore" is Ignored by the "Connect-VIServer" CmdLet

*UPDATE 2019/08/08*: Here is the entire script I'm using:

# Force the use of Windows Credentials as Proxy Auth for the current session

[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials;

# Verificar si VMWare CLI está instalado

If ((Get-Module -Name VMware.PowerCLI -ListAvailable) -ne $null) {

    # VMWare.PowerCLI ya se encuentra instalado

} Else {

    # Verificar si el repositorio 'PSGallery' se encuentra habilitado

    If ((Get-PSRepository | Select-Object -Property Name | Select-String -Pattern "PSGallery" -CaseSensitive -SimpleMatch) -ne $null) {

        # El repositorio está instalado

    } Else {

        # Restore the Default Repository "PSGallery" "https://www.powershellgallery.com/api/v2"

        Register-PSRepository -Default -Verbose;

    }

    # Set the Defualt Repository as Trusted

    Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted;

    # Instalar VMWare.PowerCLI

    Install-Module -Name VMware.PowerCLI;

}

# Mostrar la configuración actual de VMWare.PowerCLI

Get-PowerCLIConfiguration;

#Get-Help about_invalid_certificates;

# Permanent PowerCLI exceptions

#   %USERPROFILE%\AppData\Roaming\VMware\PowerCLI\SslCertificateExceptions.csv

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false -Scope Session -ProxyPolicy UseSystemProxy -ParticipateInCeip $false -DisplayDeprecationWarnings:$true -DefaultVIServerMode Multiple;

Connect-VIServer -Server somehost.domain.com -Force -Verbose;

# List VM Machines

Get-VMHost;

# Wait for a key press to finish the script

Write-Host -NoNewLine "Press any key to continue...";

$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown");

[LucD]

That option is working for most of us.
It could be an issue related to the regional settings.

Can you check while running with the setting to EN/us?

I would in any case suggest to open a SR.

[edgerch]

Hi LucD​ thanks for your answer.

I've tried to change the regional settings on my computer but no luck...

My Regional Settings are:

- ES-GT

[LucD]

It could also be related to your Name Resolution (DNS) and the Certificate on the VCSA.

If the hostname of the VCSA doesn't resolve in both directions and the certificate only contains the FQDN but not the IP, you might also get this error.

Can you resolve the VCSA FQDN and IP on your station and on the VCSA?

[edgerch]

Hi LucD​...

Yes, I can resolve "ping somehost.domain.com" to an IP, 192.168.90.1 for example... I also can revolse "ping -a 192.168.90.1" to somehost.domain.com

[sjesse · Accepted solution]

I remember getting this before, I think I was trying to run something inside of a guest using invoke-vmscript, you could try this but I'm not sure it will work or not based on the error

add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
    public bool CheckValidationResult(
        ServicePoint srvPoint, X509Certificate certificate,
        WebRequest request, int certificateProblem) {
        return true;
    }
}
"@
$AllProtocols = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here

.

[LucD]

The issue could also be caused by the TLS version.
Can you try running the following, before doing the Connect-VIServer?

[System.Net.ServicePointManager]::SecurityProtocol =  [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'

[edgerch]

Many thanks sjesse​ and LucD​!!! This worked for me!!!