HTTPS Verification for WSMan on Linux

Summary of the new feature/enhancement

Currently there is a hardcoded check that makes sure -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck) is set when a HTTPS connection is made on WSMan on non-Windows hosts. This is because the OMI library that is shipped with PowerShell does not implement any certificate validation making the user be explicit that they know no validation is happening.

I’ve got a fork of the OMI libraries that implements HTTPS validation and I’m struggling to define the default behaviour and potentially ways of integrating it into PowerShell making it a better end user experience.

Right now the behaviour in that PR is to enable HTTPS validation by default even though PowerShell requires you to use the -SkipCACheck -SkipCNCheck session options when creating the connection. To actually opt out of validation the env vars OMI_SKIP_CA_CHECK and OMI_SKIP_CN_CHECK do the same as the the -Skip*Check options. This is not ideal for a few reasons

• End users still need to have -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck) when creating the session
• It’s somewhat confusing as the options contradict with what the library does
• Env vars set in .NET on non-Windows aren’t actually set in the process, so doing $env:OMI_SKIP_CA_CHECK = '1' in PowerShell won’t reflect in the unmanaged code
  • You either need to set the env vars when you start the process or PInvoke to call setenv or unsetenv directly

I decided to enable verification by default because that’s what should be done for HTTPS connections and I see it as the easiest way of potentially integrating it into PowerShell. The change hasn’t been merged yet so I’m happy to hear any other suggestions.

Proposed technical implementation details (optional)

My overall goal is that when using the OMI fork I have the requirement of setting the skip options is dropped and once that is done the skip options are actually passed down into the OMI library and it works just like it does on Windows. For that to occur I believe the check needs to move out of this repo and down into https://github.com/PowerShell/psl-omi-provider. That library can then have some check to see if the default OMI library is present or whether my fork is used and act accordingly.

What I’m hoping to get out of this issue is just a general viewpoint from the PowerShell team and whether they would be open to moving this check and potentially even guidance on how to get psl-omi-provider to see the upstream fork is used and drop the check that makes sure the SSL checks are skipped.

[jborean93]

With https://github.com/PowerShell/PowerShell/pull/13786 being merged I feel like this issue has been fixed as best as it can. I’ve also created a 2.0.0 release which contains the updated mi and psrpclient libraries that will read the session options when using pwsh 7.2.0 or newer. For existing versions it will still continue to validate the cert and require the env vars to disable but at least there is a way forward for the future.

Finally I’ve also published the changes in a module called PSWSMan on the gallery. For non-Windows users who wish to use this fork they can just run the following as root

Install-Module -Name PSWSMan -Scope AllUsers
Install-WSMan

This will install my forked copies of libpsrpclient and libmi for the distribution they are on. The PSWSMan module also contains a few other helper functions to disable cert verification globally as well as set up a trusted CA certificate for HTTPS. People can update that module as new changes come in and install the latest ones for their Linux distribution.

[jborean93]

Thansk @SteveL-MSFT (and the committee) for looking into this. After having a brief look at the code I think I can see a way to check whether HTTPS validation is available. PowerShell could potentially call WSManGetSessionOptionAsDword with the options WSMAN_OPTION_SKIP_CA_CHECK and WSMAN_OPTION_SKIP_CN_CHECK. Currently the libpsrpclient that implements this function for Linux would return MI_RESULT_NOT_SUPPORTED. If libpsrpclient was updated to support passing those flags through it would mean it is aware that the underlying OMI library supports HTTPS or not and will pass through the options correctly to ignore the certs.

One final question, would the PowerShell team be willing to accept the change(s) in https://github.com/PowerShell/psl-omi-provider or is this something I would also have to fork and compile myself to include the changes?

<div> GitHub</div><div>PowerShell/psl-omi-provider</div><div>PSRP Linux support library. Contribute to PowerShell/psl-omi-provider development by creating an account on GitHub.</div>