pspete / psPAS

PowerShell module for CyberArk Privileged Access Security REST API
https://pspas.pspete.dev
MIT License
296 stars 91 forks source link

Could not create SSL/TLS secure channel Powershell 5? #110

Closed orionneo closed 5 years ago

orionneo commented 5 years ago

Your Environment

Expected Behaviour

Authentication via New-PASSession should work 100%.

Current Behaviour

When we are attempting to authenticate via the following command:

$token = New-PASSession -Credential $Credentials -BaseURI $URL

The following error is reported:The request was aborted: Could not create SSL/TLS secure channel. Invoke-PASRestMethod : The request was aborted: Could not create SSL/TLS secure channel. At C:\Users\Documents\WindowsPowerShell\Modules\psPAS\Functions\Authentication\New-PASSharedSession.ps1 :91 char:18

It is not about certificate which is valid and verified even if we check the PVWA in our browsers.

The powershell version is the following: Major Minor Build Revision


5 1 15063 1387

If I run the same command on PowerShell 6, just for testing, it works (on the same machine):

PS C:\Users> $token

sessionToken BaseURI


{Authorization} https://xxxxx

To summarize, the authentication works with powershell 6 but not with powershell 5. We would like to stick with PS 5, but we couldn't determine the root cause for this.... can you please support?

pspete commented 5 years ago

You have logged the issue against New-PASSession, but the error message you provide is related to New-PASSharedSession - can you clarify with which function you see the error?

orionneo commented 5 years ago

Hi Pete, the issue is happening to both!

pspete commented 5 years ago

you've set bindingConfiguration="httpsBinding" against the relevant authentication services in the web.config file?

orionneo commented 5 years ago

We have only Rewrite configuration and a rule to route http to https. What is weird is that with PS 6.0 it works! but not with PS 5.x~ Any hints?

pspete commented 5 years ago

The module attempts to force use of TLS1.2 if it is available. [Net.SecurityProtocolType].GetEnumNames() will give you the available security Protocols [Net.ServicePointManager]::SecurityProtocol will show you what is currently in use.

Check the [Net.ServicePointManager]::SecurityProtocol output before and after attempting to authenticate in both PowerShell 5 & PowerShell Core to see if there is any difference in the protocol being used:

PS>[Net.SecurityProtocolType].GetEnumNames()
SystemDefault
Ssl3
Tls
Tls11
Tls12

PS>[System.Net.ServicePointManager]::SecurityProtocol
Tls12
pspete commented 5 years ago

In PSCore, does the following return a 200 response?

Invoke-WebRequest -Uri https://YourPVWA/PasswordVault/ -SslProtocol TLS12

NathanielMaier commented 5 years ago

orionneo - If you didn't realize, base64 performs encoding, not encryption. Regardless of this troubleshooting, you've now posted your username and password to the public Internet and also shared your company's internal PVWA address.

I recommend you change your password imeditately.

pspete commented 5 years ago

@orionneo - it appears the difference in behaviour you see in the module between PS5 & PSCore is that TLS1.2 is not currently enforced when using PSCore, which I will remedy in an upcoming release. That being said - this update would mean you will likely see a TLS related error when using either PS5 or PSCore.

orionneo commented 5 years ago

Hi Pete,

Just to update you, I have re-installed the module after the last update, and it looks like it is working properly now.... any explanations?

pspete commented 5 years ago

Good to know your issue is fixed. Between v2.2.2 & v2.3.0 of the module, the only thing which changed is that the -SSLProtocol parameter is specified on the Invoke-WebRequest call with a value of TLS12 when the using PSCore. The rest of the updates all relate to new API features present in Cyberark 10.5. There were no changes to the logic of the authentication or web service call which would be used for PowerShell 5 at all.

pspete commented 5 years ago

@orionneo - I believe this is resolved for you now, so closing the issue.