Make IgnoreSSLErrors parameter on New-ISHSession and Test-ISHSession to have local scope

[Sarafian]

Current if someone executes New-IshSession -WsBaseUrl $uri -IgnoreSslPolicyErrors or Test-IshSession -WsBaseUrl $uri -IgnoreSslPolicyErrors then all certificate validation is ignored for the lifetime of the process.

As the parameter is defined on the cmdlet, it's scope should be for the scope of creating the session and using the session by the rest of the cmdlets.

But it should not affect anything else

[ddemeyer]

Please elaborate technically how to do this... I seem to remember it is tied to the AppDomain. -Dave

[Sarafian]

This is not easy to achieve. Having said that a couple of ideas

• Tunable-SSL-Validator. The readme is a copy from a blog post that explains a lot but the idea needs to be adapted for ISHRemote
• The validator function needs to somehow know the session that triggered it. This is not going to be easy therefore I would advice something else. Instead of controlling this setting from the cmdlet, offer cmdlets that add the host with the issue to an exception list. Similar to @Jaykul ApproveLastRequest function. What he does is that he tracks the invalid certificates. And adds the last to the exception list. From this point that hostname is valid for everyone.

1. First set the callback to be able to track.
2. Try a request to e.g. "https://invalidhostname/
3. Capture the last certificate and add it to a list
4. Next time the callback gets activated, look inside the list for exceptions.

Pretty much this is what happens inside @Jaykyl implementation

[Jaykul]

I feel summoned ...

For what it's worth, you're welcome to use my code under your Apache license. If you're adding a parameter on your own command, you can probably handle it the same way my proxy commands for the built-in network commands do: just call TunableValidator.ApproveNextRequest() before you make each ssl request.

However, if I understand how this module's being used, a better solution is probably to just make available a Trust-Domain command based on Request-WebCertificate and Add-SessionTrustedCertificate ...

[Sarafian]

I would like to avoid making changes to the operating system. PowerShell is in general a non parallel executing environment. I like your approach @Jaykul because it's build upon this idea. I run into this issue because I needed to run some pester testers against localhost while the certificate has a common name like ish.example.com. I didn't want to permanently change the OS and neither remove all certificate validation for the powershell session.

To work around the issue of ISHRemote and actually all other tests that accesses url's like https://localhost/ I do this in the test

Describe "test" {
    BeforeAll {
        Enable-SSLOverrideForLocalHost
}
    AfterAll {
        Disable-SSLOverrideForLocalHost
    }
    It "Test ISHWS ConnectionConfiguration.xml" {
        $uri="https://localhost/$($deployment.WebAppNameWS)/ConnectionConfiguration.xml"
        Get-UriStatus -Uri $uri | Should BeExactly 200
    }
}

To support this flow I wrapped a bit of @Jaykul functionality

function Enable-SSLOverrideForLocalHost
{
    begin {
        if (-not ("Huddled.Net.TunableValidator" -as [type]))
        {
            Add-Type -Path "$PSScriptRoot\TunableValidator.cs"
        }
    }
    
    process {
        try {
            [Huddled.Net.TunableValidator]::SetValidator()
            Get-UriStatus -Uri "https://localhost"            
        }
        catch
        {
            [Huddled.Net.TunableValidator]::ApproveLastRequest()
        }
        finally
        {

        }
    }
    
    end {
    
    } 
}
function Disable-SSLOverrideForLocalHost
{
    begin {
    }
    
    process {
        if ("Huddled.Net.TunableValidator" -as [type])
        {
            [Huddled.Net.TunableValidator]::TrustedCerts.Clear()
            [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $null
        }

    }
    
    end {
    
    } 
}

Get-UriStatus is wrapper around Invoke-WebRequest focused on my test functionality.

I could had extracted and/or enhanced the functionality of TunableValidator.cs and use only the required feature, but I found the [Huddled.Net.TunableValidator]::ApproveLastRequest() very handy to move forward.

[ddemeyer]

Resolved in #115, so ISHRemote v7+