dbailey12
Contributor
Contributor

Certificate validation with Connect-VIServer (PowerCLI 10.0 & 6.5.4.7155375)

I'm trying to resolve a certificate validation issue I'm seeing in PowerCLI.

(I know I can just set -InvalidCertificateAction to Ignore or save the thumbprint as an exception in PSTCS as a workaround.)

When I have InvalidCertificateAction set to Prompt, I get:

> Connect-VIServer myviserver.blah.net -Verbose   
WARNING: There were one or more problems with the server certificate for the server myviserver.blah.net:443:  

* The certificate's CN name does not match the passed value.  
Certificate: [Subject]    CN=myviserver.blah.net 
[Issuer]    CN=myCA DN

I'm not sure what it doesn't like about the CN... it matches and browsers don't complain. I tried messing with [System.Net.ServicePointManager]::SecurityProtocol based on some other threads but that didn't seem to help.

Does anyone have ideas on how to investigate further?

Thanks!

0 Kudos
20 Replies
LucD
Leadership
Leadership

Which type of vCenter, and what version?

Is it with an embedded PSC?

Did you check the SSL Trust Anchors?

See for example Task 0 in KB2121701

Did you try connecting with an Invoke-WebRequest?

What does the StatusCode say?


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

dbailey12
Contributor
Contributor

Hi thanks for the response,

I've tested against - 6.5.0 (7801515 and 7515524) VCSAs. Tried with vCenters that both have an embeded PSC and ones that do not.

SSL Trust Anchors look good.

I should have considered Invoke-WebRequest. Like I mentioned I had tried playing with ServicePointManager::SecurityProtocol and in the session where I had done that, Invoke-WebRequest succeeded. In a fresh sesssion, it's failing. We're enforcing TLS 1.2 on the server side. Perhaps the ServicePointManager settings aren't applying to Connect-VIServer. I'll dig into SCHANNEL registry settings etc and see if I can figure it out.

Hopefully someone at VMware sees this and investigates whether PowerCLI can throw a better warning if it's reallly a TLS protocol negotiation issue rather than a CN mismatch isssue.

Thanks again!

0 Kudos
LucD
Leadership
Leadership

You're apparently not alone, there has been mention of the same issue on the VMware{Code} Slack channel.

It looks more and  more like this might indeed be a PowerCLI 10 issue.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
kmruddyVMW
Enthusiast
Enthusiast

If at all possible, please open a support request. We definitely want to make sure to get this in front of our engineers.

Also, add a link to this thread in the SR as well.

dbailey12
Contributor
Contributor

Will do but we don't have API level support and I've had VMware balk at PowerCLI tickets before with our support level. I'll also ping our account reps.

FYI, if I set SchUseStrongCrypto in the .NET registry keys  (per ssl - .Net Framework 4.6.1 not defaulting to TLS 1.2 - Stack Overflow ) Invoke-WebRequest will work and

[System.Net.ServicePointManager]::SecurityProtocol defaults to "Tls, Tls11, Tls12". However, Connect-VIServer still fails with this in place.

0 Kudos
LucD
Leadership
Leadership

On the support question, refer them to PowerCLI Support Breakdown, it is supported for the areas marked in that post!
And in this case it looks like it fits in "If you’re using a cmdlet and you’re hitting some form of error, where the command used to work or should work according to the documentation, a support request can be opened. "


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

dbailey12
Contributor
Contributor

SR has been opened. Thanks all, I'll try to update with the results.

0 Kudos
dbailey12
Contributor
Contributor

This occurs in PowerCLI 6.5.4.7155375 as well. Looking at Wireshark, it appears TLS 1.2 is being negotiated ok accross the network when running Connect-VIServer, so the problem appears above that level.

 

The first-level support engineer was able to replicate but is suggesting that prompting to accept valid certificates the first time is the intended behavior. I've asked him to escalate and clarify that because if that's the case it's unclear in the documentation.

0 Kudos
LucD
Leadership
Leadership

That 'sounds' not right.


Or do they use that confirmation to store the certificate in the user's cert: store?
But what if it is already in the computer's cert: store through a GPO for example?


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
dbailey12
Contributor
Contributor

Yeah, it doesn't make much sense.

In my case, the cert is trusted in both the user and computer store in Windows (not just the CA for testing).

The only way I can imagine it's working as intended is if they're disregarding the Windows's trust settings and relying solely on the "POWERCLI TRUSTED CERTIFICATE STORE (PSTCS)"

However, I understood the PSTCS as a place to store exceptions that weren't trusted by Windows.

0 Kudos
LucD
Leadership
Leadership

Yes, perhaps a blog post on the subject by those in the know would be helpful Smiley Wink


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
AtanasAtanasov
VMware Employee
VMware Employee

What is the OS and version of .Net Framework?

0 Kudos
LucD
Leadership
Leadership

Windows 10 build 1709

.NET Framework 4.7.1


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
AtanasAtanasov
VMware Employee
VMware Employee

Is it PowerShell 5.1 or PowerShell Core 6.0?

0 Kudos
LucD
Leadership
Leadership

For me it is 5.1


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
dbailey12
Contributor
Contributor

Same:

> $PSVersionTable

Name                           Value

----                           -----

PSVersion                      5.1.16299.248

PSEdition                      Desktop

PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}

BuildVersion                   10.0.16299.248

CLRVersion                     4.0.30319.42000

WSManStackVersion              3.0

PSRemotingProtocolVersion      2.3

SerializationVersion           1.1.0.1

Windows: Version 10.0.16299 Build 16299 (also reproduced on Server 2012R2)

0 Kudos
dbailey12
Contributor
Contributor

The message in the prompt about the CN mismatch is spurious and I've asked the support tech to submit a "feature" request to address that.

Beyond that, PowerCLI does not use the Windows certificate store so you must accept the prompt or manually add the certificate to the PowerCLI Trusted Certificate Store (PCTCS).

0 Kudos
cking2
Contributor
Contributor

Not sure I buy that. I learned that PowerCLI is now on PSGallery so I uninstalled whatever verson (MSI version) I had which did not bark about our (perfectly valid) certificates.

I installed 10.0.0.7895300 from the Gallery. I used to be able to just do a Connect-VIserver FQDN and it connected as the user running the PS session. Now it both prompts for creds and then complains about certificate.

Same with PowerShell Gallery | VMware.PowerCLI 6.5.4.7155375

Uninstalled everything and installed 6.5 release 1 Build 4624819 from the MSI and shows certificate ok and just logs in.

If you trying to say the new behavior is to only PowerCLI Trusted Certificate Store (PCTCS) then that should be in the (new)DOCS.

Also, anyone see the same behavior on the creds issue?

0 Kudos
AtanasAtanasov
VMware Employee
VMware Employee

The issue with false errors with valid certificates would be fixed in the next release. My investigation show that you should be able to use the Ignore or Fail values for the InvalidCertificateAction setting of PowerCLI - to either ignore all or validate all certificates. For single exceptions, you can use the -Force parameter of Connect-VIServer. Those should work correctly and across all platforms.

0 Kudos