The client and server cannot communicate, because they do not possess a common algorithm on Windows Server 2008 Web

Question

I am working on a ASP.Net WebForms application. We are using PayFort's Start API for the payment process. The application is running fine on our local machine (Windows 10) but it shows following error when we try to make payment using their API on our deployment server (Windows Server Web 2008).

The client and server cannot communicate, because they do not possess a common algorithm.

The documentation on their webpage (PayFort Start and SSL/TLS) states that they use Tls1.2 for the communication. Their API already contains the code to use Tls1.2 as Security Protocol

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

We've built the application on .Net framework 4.5 since Tls1.2 only supported by .Net 4.5 or later. Needless to mention, our server has .Net Framework 4.5 installed in it.

We've also added the registry values for Tls1.1 and Tls1.2 in the windows registry

Using the SSL Labs tool, we've also confirmed that there are atleast two Cipher suites supported by both servers (our server and PayFort's API Server) (https://api.start.payfort.com)

Cipher suites supported by PayFort's API Server (Green outlined are those which are common with our server)

Cipher Suites supported by our server

I've also used the Nartac IIS crypto software and it's showing the following info as Best Practices

I'm not sure if it has anything to do with the problem or not, but here are the details of the SSL certificate installed in our server


Can anyone please point out that what we are doing wrong and what should we do in order to communicate with the desired server and make payment from the application deployed on our server as we are doing perfectly on our local machine.

Answer 1

I'm with the Payfort Start team. We've got a page here that helps describe this issue in more detail. Essentially, your API client (the library you're using to make the HTTPS request) has to support TLS1.2. The Start API will reject any request that doesn't support TLS1.2 at a minimum.

It would appear that the WebRequest does support TLS 1.1 and 1.2, but you have to turn them on manually. You can refer to this answer for the fix.

To verify that your client supports TLS1.2, you can send a GET request from your application to https://www.howsmyssl.com/a/check and read the response.

In cURL:

> curl -X GET https://www.howsmyssl.com/a/check

Returns:

{
  given_cipher_suites: [
    "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
    "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_RC4_128_SHA",
    "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
    "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
    "TLS_RSA_WITH_RC4_128_SHA",
    "TLS_RSA_WITH_RC4_128_MD5",
    "TLS_RSA_WITH_AES_128_CBC_SHA",
    "TLS_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA"
  ],
  ephemeral_keys_supported: true,
  session_ticket_supported: true,
  tls_compression_supported: false,
  unknown_cipher_suite_supported: false,
  beast_vuln: false,
  able_to_detect_n_minus_one_splitting: false,
  insecure_cipher_suites: {
    "TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA": [
      "uses keys smaller than 128 bits in its encryption"
    ]
  },
  tls_version: "TLS 1.2",
  rating: "Bad"
}

Look out for the tls_version at the end.

Answer 2

The problem was the Operating system. We were using Windows Server 2008 and we didn't realize the application need OS's protocol to communicate with other server. Since we have .NET Framework 4.5 installed and we were also using the code ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; to force application to use Tls1.2 (according to the requirement), hence believed that everything should work fine, but obviously this wasn't going to happen.
tl;dr; We installed Windows Server 2012 on the machine and the application is running fine now (as it should)