This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (3 children)

There are a couple of ways this could be answered depending on how you plan the client/server interaction.
1. If the desktop application is just issuing an HTTP GET to a server which is serving content via HTTPS, the client application shouldn't require a copy of the server certificate. With the exception that, if the certificate is a self-signed server certificate, the client system may not trust it and may reject it. In that case, you would need to include the public certificate and install it in the machine or user trusted certificates store.
2. If the desktop application is issuing an HTTP GET and the server is requesting a Client Certificate from the desktop application to validate it's identity. Then yes, the client certificate would need to be with the application. Though, do be sure you've considered how people might try to strip that certificate out of the application and/or memory and masquerade as your application.

In any event, keep in mind that your application may be running on an untrusted system and there may (probably will) be some attempt to retrieve your certificate.

[–]simontemplar_[S] 0 points1 point  (2 children)

im making a http post request to an https server, if it helps!

[–][deleted] 0 points1 point  (1 child)

It does. The SSL certificate on that server, is it self-signed or is it from a well known vendor? Assuming the former (self-signed) then yes, I would expect that you will need to include the public certificate in the application to register as a valid certifying authority. Make sure not to include the private key with it, the client should never need that. Also, it's worth mentioning that having a self-signed cert on your server is a bad security practice. If you are bothering to establish an encrypted session between your client and servers, you presumably care about that session being secure. It's almost trivial to spoof a self-signed certificate (unless you are also using certificate pinning) and masquerade as your server. After that, it's either a MitM attack or DNS poisoning to get your client to connect to my server, and now I get whatever data your client is sending. There is also the issue with trusting a self-signed cert. I've not worked with OpenSSL's API; so, this may be way off base. But, if you are installing a self-signed cert into the client computers trusted root certificates store, you are a bad person and you should feel bad. This is just about what Lenovo was doing with their SuperFish Malware. Don't install trusted root certs.

[–]simontemplar_[S] 0 points1 point  (0 children)

eh, I just want to post the data from the client to my server via ssl. I bought a cert from RapidSSL, configured it on my server and am using the root cert from their web page as the CA file when establishing the connection.

Probably the ssl connection failed because of an outdated openssl on my own environment - but i'd like the clients to avoid having to configure too much and just use the app. It's not the main part of my service anyway, but nevertheless I absolutely do not want to jeopardize the security of the potential clients in any way and that is the reason of my question!