I'm not sure whether this topic belongs in Cryptography, Programming or StackOverFlow so please forgive me if I don't add a useful question to this site.

I want to give both server and client programs (.jar archives) to my users.

  • The SERVER is a mod for a game (has one server-id)
  • The CLIENT is a smartphone that is supposed to control the game by sending messages to the server (has one client-id)

I wanted to keep everything encrypted so I think SSL is a good choice. Because the Server is actually not mine what I did was let the server create a self-signed certificate and store it

Because accepting any certificate can be exploited, e.g. the attacker could spoof the server-id of another server and my client app would send the internal password (not SSL related) to the attacker. The attacker could now spoof the client-id and has control over a game

How should I implement the client so that it verifies and distinguishes servers by their certificate?

  • Will you centraly sign the server's certificates (so you act as CA) or will you do "Trust-On-First-Use"? If you do use "Trust-On-First-Use" you'd "just" verify the certificate you see this time is the same as you saw last time and then you're safe.
    – SEJPM
    Nov 26, 2015 at 21:23

1 Answer 1


With most TLS implementations you just need to store the self signed certificate of the server in the trusted certificate store. You may have to add a specific option to the command line or API call to mark the certificate as trusted.

In that case the chain of the server certificate leads to a trusted certificate because the server directly uses the trusted certificate (i.e. a "chain" of one certificate).

You do need to establish trust before establishing the connection, e.g. by distributing the self signed certificate with your client application.

  • Could I let the server broadcast their certficates and set their server-id to the SHA-256 of the encoded certificate? The client would trust every certificate but would verify the server-id.
    – KeksArmee
    Nov 27, 2015 at 15:11
  • Anybody could send any certificate, right? So I don't see any trust relationship being established that way. If you already know the certificate then you can just as well store the certificate itself. Nov 27, 2015 at 23:29
  • Sorry, I forgot to mention that the client has to create an "account". The server will save [client-id, sha256salt(password of account)] and the client will store [sha256(public key), password of account]. If the attacker doesn't know the private key, he cannot decrypt incoming data. If the attacker gives any public key he won't get the account password
    – KeksArmee
    Nov 28, 2015 at 19:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .