Recently Cybersource updated their cypher suites and TLS to the 1.2 TLS and the following cipher suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
Several applications running on Windows 2012 R2 will no longer connect to the Simple Order API after this. Some, which require explicit setting of TLS 1.2 because of older .NET Framework, and others which are not the latest but still can automatically use TLS 1.2.
Typically the applications are .NET Framework 4.6.2 ASP.NET. Some are older - possibly .NET Framework 4.5.2. The older ones are the ones where we have had to set the TLS version in the past I believe. Applications with the same general code base (4.6.2) are running just fine as expected without any code updates on a Windows Server 2016 web server. This is why I think it is a server issue more than the code issue and why I specified the cipher suites specifically.
Is there any possibility that .NET Framework version is responsible for the security error "Could not establish secure channel for SSL/TLS with authority 'ics2wstesta.ic3.com'?"
Or is this a settings issue on the web server? The Knowledge article from cybersource indicates that this is a setting issue. And some articles I have found on Microsoft and elsewhere suggest some group policy settings to prioritize the cipher suites above. But I want to make sure before I hand it over.
Ultimately this seems like it was a Group Policy which was not properly configured in Windows Server 2012R2. I am not familiar with how this was resolved exactly, as I did not do it, but that is the direction which was required. A more server-oriented IT person would know the answer I'm sure.