I have designed a desktop application using windows forms app.
It will be receiving a pop-up message whenever an updated version is available on the server.
I have generated an API which consists of the updated version of the desktop application which is been used as the server with the help of the ngrok and I have enabled the SSL for the API. The SSL certificate is been installed into trusted root certification authority.
Now how to use the SSL for server validation(that is the clients who the SSL only need to hit the server and can download the updated version)?
Please, someone help me in solving this issue.
I have an application that can be downloaded from our website and runs on user PC.
This application provides connection between our hardware and our web application. It uses SignalR for communication.
Basically, I run SignalR server under WinForms application and have javascript client that tries to access it through http://localhost:8084/signalR.
Everything works fine when I use HTTP version of the web application, but fails, when I use HTTPS for my web application:
Most of the browsers don't allow unsecured connections from a secure page.
So, my question is how can I have self-signed certificate included in my software which installs certificate on user pc during installation and how can I make it work in the way that browsers not complaining about unsecured connection?
If you run SignalR server on user PC each user must obtain the certificate for SignalR connection it launches. Self-signed certificate would be reasonable decision for an Intranet or development. It isn't safe enough for the internet. Another possible problem is retrieving name of the machine where SignalR is running. Certificate attaches to certain local machine(I could be wrong at this) and for connecting to client's application SignalR server you need to know the name of machine he uses. Migrating SignalR server from client to web app server will solve mentioned troubles.
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.
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.
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)
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
I have a client-server application written in c#. I am hoping someone can give some direction on where to look in order to set it up where a user could connect to the server from their workstation, most likely through http but that's not a requirement, and download the client. The mechanism would need the following features:
Check for updates on client startup and automatically apply them.
Allow multiple clients (connected to different servers) to download on the same machine
Client can be downloaded by a non-local admin
Possibly install any prerequisites needed on the workstation
I currently use ClickOnce but it isn't quite working out. Currently the server sits in IIS and uses WCF services.
I'm trying to create a client-server app where the server runs on the user's machine. I'm looking into either using WCF or Sockets but I have a couple of questions.
I'd like to use WCF but it seems that the user needs admin rights in order to launch the service. Would the user need admin rights if the WCF service was running within a managed application (e.g. a Windows Service)? With sockets it seems that admin rights isn't required to open the relevant port.
How would HTTPS security work in WCF? Since this is a LAN program (user talking from client to their own machine), do I need to purchase a certificate and install it on their machines? I'd rather avoid this if possible as the data being transferred isn't sensitive. Would this be the same if I use SSLStream for sockets?
There are a lot of questions, :), so very short answer on part of them:
You can host WCF even in console application. Windows Services may not require admin properties to be installed on pc.
For HTTPS - you does not have to buy certificate, you can crate your own - there are a lot of examples in the net. But - if your data is not sensitive - you can probably use simple http.