PowerCLI: The SSL connection could not be established, see inner exception.




Summary:
Unable to connect to ESXi/vCenter server with Connect-VIserver cmdlet, get the following error:
"The SSL connection could not be established, see inner exception."

Be sure to "Set-PowerCLIConfiguration -InvalidCertificateAction:Ignore" if you plan to connect to an ESXi/vCenter that does not have trusted certificate.  Interestingly, something must've changed recently because the PowerCLI module actually would output a more descriptive message about setting your PowerCLIConfiguration.

This appears to be the case w/ Powershell Core 6.1.  I'm actually unsure when this behavior started happening and whether is module or powershell related.  Regardless, figured I'd post this since I was initially confused myself when running some things on another system.


Comments

Michael Sheen said…
Thanks for the information.
September 28, 2018 at 1:51 AM
Anonymous said…
Thanks for the info: it solved my problem
November 21, 2018 at 4:50 AM
Thomas Léveillé said…
This error shouldn't show up if you download the root certificates and import them on your machine. You can download them from the root vsphere web page (link on the bottom right).
January 4, 2019 at 4:18 AM
Thomas Léveillé said…
Best way to get rid of this error is to download the trusted root certificates from vsphere's root web page (link on the bottom right) and import them on your operating system.
January 4, 2019 at 4:19 AM
Zsoldier said…
Yes, that is another way as well. A way to do that in Powershell would be preferred though across all OS’s. That way it can be automated.
January 4, 2019 at 9:21 AM
Post a Comment

Popular posts from this blog

NSX-T: Release associated invalid node ID from certificate

Image
Summary: Basically had an expiring certificate registered in NSX-T that was associated to a node_id that is no longer valid.  Long story short, there wasn't anything obvious in API to delete or disassociate a certificate from a node_id for 3.2.2.  Not sure how things got in this state, but annotating for future reference.  This may change in future revisions, so always check API for latest. Details: Effectively had a stale node associated w/ a certificate that was expiring.  Could not delete certificate until that node was disassociated from the certificate. To get certificate details and associated node_id's, you can use the following curl call (UI works too): curl -k -X GET -H "Content-Type: application/json" -u admin https://<manager ip>/api/v1/trust-management/certificates/<cert UUID> Above will return something like this: Below must be run from one of the manager nodes via elevation to root: ONLY RUN THIS IF YOU ARE ABSOLUTELY SURE OF WHAT YOU ARE DOI
Read more

NSX-T: vCenter and NSX-T Inventory out of Sync (Hosts in vSphere not showing up in NSX-T)

Image
Summary: NSX-T loses synch w/ vCenter inventory, but statuses don't appear to show an issue.  Basically, you add a host to a vCenter cluster, NSX-T bits should start to automatically installing on new host.  Assuming you've created a Transport Node Profile and associated w/ the cluster.  The problem is that NSX-T doesn't see the new host and its link to the compute manager (vCenter) looks fine. Looks fine, Y U NO WORK!? So what's going on here?  This appears to affect NSX-T 2.5 and 2.5.1.  Cause is unknown. Workaround: Restart the cm-inventory service on each NSX-T mgmt/controller node using API or CLI. Details: If you were to query the status of the cm-inventory via API or CLI, you could query all 3 manager/controller nodes and get a status of running.  Even if the primary node associated w/ the VIP, if configured, is not necessarily in charge of inventory.  So you could restart the cm-inventory service till you are blue in the face and get nowhere be
Read more

Azure VMware Solution: NSX-T Active/Active T0 Edges...but

Image
Summary: Azure VMware Solution (AVS) delivers by default w/ a pair of redundant Large NSX-T Edge VM's each running a T0 in active/active mode.  So why is my traffic only going out one Edge VM? Short answer: The default T1 that is delivered w/ AVS is an active/passive T1 where you connect your workloads to.  So while it could technically take either T0, it's always going to go out the closest T0 to the active "SR" T1.  Where do the SR's live?  You guessed it, on the Edge VM's.  As you can imagine, this can lead to a bottleneck if you try to shove all your traffic through a single Edge VM. Simple Diagram: Longer answer with Options:
Read more