'The client and server cannot communicate, because they do not possess a common algorithm' or SECEALGORITHMMISMATCH. Transport Layer Security (TLS) is not completely enabled on the Symantec Management Platform server. Windows Server 2008 R2 and possibly Window Server 2012.
We're trying to run a security test for one of our websites (HTTPS). When browsing it directly with our browser, there are no issues and the page just loads fine. However, when the browser is redirected to the Web Proxy tool to monitor the request/response or create a login macro, we get the message:
The client and server cannot communicate, because they do not possess a common algorithm
Steps we've attempted so far (with help from Customer Support):
1. Verify the SPI.Net.Proxy.config
2. Add the hostname of the site we'll test in the system's HOSTS file
3. Change the Advanced Settings of IE8 (Disable / Enable the following: SSL v3.0, SSL v2.0, and TLS v1.0)
4. Check that the System cryptography: Use FIPS in Local Security Policy's set to Disabled; and
5. Confirm with the site owners that it's using SSL v3 and that the issue only persists within this server hosting
Running a scan to the site also causes the scan to just stop as soon as it's started. I've attached a sample video showing the issue.
Are there other steps that we could use to approach this issue?
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
We've built the application on .Net framework 4.5 since
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
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.
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.
sohaiby
sohaibysohaiby
8653 gold badges19 silver badges36 bronze badges
3 Answers
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
tl;dr; We installed
sohaibysohaibyServicePointManager.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)8653 gold badges19 silver badges36 bronze badges
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:
Returns:
Look out for the
tls_version
at the end.Community♦
FloatingRockFloatingRock3,0615 gold badges31 silver badges48 bronze badges
I hope this can clarify your situation a bit and help:
1 Confirm that app is running under .net 4.5 (or higher).
TLS 1.2 is supported in 4.5+. To get actual version of .net framework you app is running under: https://msdn.microsoft.com/en-us/library/system.environment.version(v=vs.110).aspx
2 Enable TLS 1.2 in Windows Registry.
I just found this link to be useful with enabling TLS 1.2 The client and server cannot communicate, because they do not possess a common algorithm
Community♦
Gabriel PavelGabriel Pavel