0

I have been trying to communicate with a secure REST API using POST, passing the certificate correctly, but I keep receiving the error "The request was aborted: Could not create SSL/TLS secure channel" only on the production server.

I don't have the option to upgrade the Microsoft Windows Server 2008 R2.

Microsoft Framework 4.8 is installed, all patches have been applied, and all security protocols are enabled.

enter image description here

enter image description here

--running the same POST using POSTMAN on the server 2008 works perfectly

enter image description here

Do any of you know why PowerShell script isn't working on only the server?

Running the same Powershell script locally it works perfectly under windows 11

enter image description here

Do you guys have any suggestions? I've tried many things so far and nothing has worked :(

Thank you so much

Improve this question
3
  • 3
    You say you don't have the option to upgrade, but you are aware that Server 2008 R2 is fully end-of-life, and has been for several years now, right? This means it hasn't had any updates in that time... not even critical security patches, in spite of multiple active critical-rated CVEs. It's dangerous and irresponsible to still be using it. Commented Oct 5, 2023 at 20:56
  • 2
    It is probably also worth noting that there is a NIST requirement to support TLS1.3 by 1/1/2024. So expect services that work with the government to move to TLS1.3 in the near future. At this time if you use Microsoft Server for your OS that means upgrading to 2022, since 2019 won't support TLS1.3 for about another year. Commented Oct 5, 2023 at 21:27
  • @TheMadTechnician The details there are tricky. The publication says services must support and allow connections from TLS 1.3 clients, and government-run clients must have support for and prefer TLS 1.3 (and therefore TLS 1.3 will be used in practice for most connections), but does not require servers to remove or disable TLS 1.2 and does not claim to regulate non-government clients. This means TLS 1.2 can still be used in public-facing services, as long TLS 1.3 is also an option. Commented Oct 9, 2023 at 16:29

2 Answers 2

Reset to default
3

You may need to ensure Tls1.2 is enabled for SCHANNEL in the registry. Start at this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Tls12\Client

Create it if it doesn't already exist and make sure there's an Enabled dword set to 1. Also, any changes to the SCHANNEL configuration won't take effect until you restart the computer.

Next, check that .Net is configured in the registry to use strong cryptographic protocols:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001

Then this line in your PowerShell should actually be effective:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

But, as I indicated in a comment, you really should do whatever you need to get to permission to upgrade the server.

Windows Server 2008 R2 is fully end-of-life, and has been for several years now. This means it hasn't had any updates in that time... not even critical security patches, in spite of multiple active critical-rated CVEs. It's dangerous and irresponsible to still be using it; lawyers might use phrases like "gross negligence".

all patches have been applied...

I should hope so, as there haven't been any new patches released in several years.

The minimum safe version to be using today is Windows Server 2016 (2012 R2 also reaches end of life in less than a week.) This is the kind of thing worth finding a new job over, as you don't want to the be one held responsible when (not if) this thing is breached.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I completely agree with you. It's remarkable when individuals like you elucidate the problem and then provide such comments. I will make every effort to migrate it as soon as possible. The process is arduous, and the client is not fond of it, but they must accept it.
@AndréIT A common tactic when supporting stubborn customers like this is to tell them, "Here is your fix. I'm leaving you with a working system today. However, be advised this is the last fix we are providing for this version of Windows Server. We are not able to support it going forward. Any further issues will require first updating to a supported version before we can look at them." Then, of course, you have to stick to that mandate... but its for their own good.
Thanks, Joel. I just hit pause on my task 'cause the steps below aren't working, and I'm pushing the company to switch the OS. I'm hoping that moving to Windows Server 2022 will sort out the TLS problems and other security stuff
0

Alternatively, if upgrading is impossible, or you dont have Admin on the required machine, you may use curl for windows (the offical version, not the PS Alias) (https://curl.se/windows/) as it does include the necessary libraries for using TLS1.3

It may be a bit work to get curl to work with PS, as it does not have the same possibilities with "Web-Session" and other things built in, so you need to write yourself a wrapper for it to work, but its doable.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.