Reposting my comment above and making it the accepted answer as this is more informative to most, thanky @abbodi86 for help!
Interesting, thanks! I have the the same experience that Invoke-Webrequest fails. And I've tried to verify that the test server only has the ciphers ECDHE-RSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384 by using curl with --ciphers to force a single cipher and should be those two.
Very good idea to run the app through powershell as you can make direct comparison of the runtime and turns out you can get different results! When calling our test server (it has an IP-whitelist so no publically available) powershell-version fails and compiled binary succeeds.
PS C:\temp> [TlsTester.SslTcpClient]::Main(@("aa.bb.cc.dd", "selfsigned-cert-name"))
Client connected.
Exception: A call to SSPI failed, see inner exception.
Inner exception: The message received was unexpected or badly formatted
Authentication failed - closing the connection.
PS C:\temp> .\TlsTester.exe "aa.bb.cc.dd", "selfsigned-cert-name"
Client connected.
Certificate error: RemoteCertificateChainErrors
Certificate Subject: CN=selfsigned-cert-name, OU=Test, L=xx, O=yy, C=FI
Certificate Issuer: CN=selfsigned-cert-name, O=yy, C=FI
Certificate Handle: 8416496
Authenticated using:
* CipherAlgorithm: Aes256(256)
* KeyExchangeAlgorithm: 44550(256)
* HashAlgorithm: Sha384(0)
When I tried it with learn.microsoft.com, both fail.
PS C:\temp> [TlsTester.SslTcpClient]::Main(@("learn.microsoft.com"))
Client connected.
Exception: A call to SSPI failed, see inner exception.
Inner exception: The function requested is not supported
Authentication failed - closing the connection.
PS C:\temp> .\TlsTester.exe learn.microsoft.com
Client connected.
Exception: A call to SSPI failed, see inner exception.
Inner exception: The message received was unexpected or badly formatted
Authentication failed - closing the connection.
I tested that server with my curl tool, it does not support ECDHE-RSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384 but forces a TLS 1.3 with TLS_AES_256_GCM_SHA384 (this seems to be the only supported one).
OK, CIPHER FOUND: Cipher selection: ECDHE-RSA-AES128-GCM-SHA256
FAIL, CIPHER CHANGED: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
OK, CIPHER FOUND: * Cipher selection: ECDHE-RSA-AES256-GCM-SHA384
FAIL, CIPHER CHANGED: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
I think the reason is that there are multiple versions of schannel.dll (several actually) and powershell invokes one and .NET-runtime another. There's still a ton of uncertainty how/where/why those are distributed. But optimistically it might be possible backport TLS-cipher support by using a different schannel.dll (with ones own responsibility).
C:\>dir schannel.dll /s
Volume in drive C has no label.
Volume Serial Number is 10D8-D7C2
Directory of C:\Windows\System32
27.04.2023 08:49 434 176 schannel.dll
1 File(s) 434 176 bytes
Directory of C:\Windows\SysWOW64
27.04.2023 08:40 359 936 schannel.dll
1 File(s) 359 936 bytes
Directory of C:\Windows\WinSxS\amd64_microsoft-windows-security-schannel_****
26.04.2021 02:21 66 858 schannel.dll
24.01.2022 06:15 1 520 schannel.dll
01.01.2022 07:21 435 712 schannel.dll
21.02.2022 03:50 12 schannel.dll
21.03.2022 03:59 12 schannel.dll
25.04.2022 02:12 58 492 schannel.dll
22.05.2023 04:19 65 465 schannel.dll
22.05.2023 04:15 435 200 schannel.dll
22.05.2023 04:19 42 384 schannel.dll
27.04.2023 08:49 434 176 schannel.dll
26.04.2021 02:24 52 590 schannel.dll
24.01.2022 06:19 1 100 schannel.dll
01.01.2022 07:07 359 424 schannel.dll
21.02.2022 03:52 12 schannel.dll
21.03.2022 04:02 38 950 schannel.dll
25.04.2022 02:13 46 335 schannel.dll
22.05.2023 04:22 53 137 schannel.dll
22.05.2023 04:15 359 936 schannel.dll
22.05.2023 04:22 45 364 schannel.dll
27.04.2023 08:40 359 936 schannel.dll