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!
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
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!
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
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.
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.
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
SR has been opened. Thanks all, I'll try to update with the results.
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.
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
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.
Yes, perhaps a blog post on the subject by those in the know would be helpful
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
What is the OS and version of .Net Framework?
Windows 10 build 1709
.NET Framework 4.7.1
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Is it PowerShell 5.1 or PowerShell Core 6.0?
For me it is 5.1
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
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)
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).
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?
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.