I'm creating an application with a client-server architecture using SSL via TCP. Clients can authorize themselves on the server using login and password and become users. Only users can perform any actions with their accounts. Unauthorized clients can only authorize themselves.

Now clients only with my client app using my server, but I think it will be ok if somebody will use third-party app.

As I understood, now only my server authorize itself for the each client, so each client know that this is a real server. Server test command:

openssl s_server -key server.key -cert server.crt -accept 1678

On the client side I have only .der certificate.

So, the questions:

  1. Is this understanding correct?
  2. Do I also need a client side keys for clients authorizations on the server, or this is enough for described architecture?
  3. Do I need a CA cerificate or self-signed certificate will be the same?

closed as unclear what you're asking by Steffen Ullrich, Serge Ballesta, Xander, Steve, this.josh May 31 '17 at 6:34

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Your descriptions of the architecture is very vague. Within this vague description both self-signed certificates would be enough and client certificates would not be needed. But, if you would add more clear security and usability requirements to the description it might be possible that this might rule out self-signed certificates and might need client certificates. Since this detail is missing I propose to close the question as too broad. – Steffen Ullrich May 29 '17 at 4:24
  • @SteffenUllrich thanks for your comment. Can you say which exactly details I need provide for more specific question? – don-prog May 29 '17 at 6:27
  • 1
    As for self-signed: do you have an app and use certificate pinning or is it acceptable for the client to explicitly override the warning coming with self-signed certificates, of course after explicitly checking the fingerprint? As for client-certificate: do you need more security as provided by username+password or not? And how will the client certificate be created and distributed? – Steffen Ullrich May 29 '17 at 6:56
  • 1
    The part you don't understand is only relevant if you use a browser based app and not a "native" app. And if username and password is sufficient authentication then you don't need client certificates. – Steffen Ullrich May 29 '17 at 18:33
  • 1
    Given that all of these certificates are self-signed and the results you got from your tests it sounds properly setup. – Steffen Ullrich Jun 1 '17 at 6:33
  1. Yes, in the usual TLS/SSL case, only the server authenticates itself to the client and not the other way round. To create trust for this authentication on the client side, you need to store either the server certificate itself (or its fingerprint) or a list of certificates from trusted certification authorities.
  2. Since you are describing, that your users authenticate themselves via username and password, TLS client authentication is not neccesary. You could replace your user authentication with it or augment the security of your system by using both schemes but you can live without it.
  3. You do not need a certificate signed by a public CA. If you are using a self signed certificate you need to store it in your client application and provide it to all third-party-client vendors. You have to take care though, if you plan or need to rollover the server's certificate, since that will become more complicated without using a trusted issuer certificate (You cannot just switch to a new certificate signed by the trusted CA but have to create the new self-signed some time before using it, include it into the trust store of your app and wait till all your users have updated).
  • A better approach is to create your own CA (Certificate Authority) root certificate with a long expiry and load the public key for that into all client computers certificate stores. Then you can roll over your operating certs without having to revisit every client PC. You MUST keep the CA root cert absolutely secure though of course. – Julian Knight May 29 '17 at 19:56
  • 1
    Here is a script that correctly creates root and server certs. github.com/TotallyInformation/SelfSigned-Cert-Creator – Julian Knight May 29 '17 at 19:57
  • @Julian Knight: I have to disagree. Rolling you own CA is not really a good idea, unless you really know, what you are doing. – mat May 29 '17 at 22:07
  • That's why I wrote a script to do it properly in a consistent way. ;-) It can actually be a LOT more secure than using 3rd party CA's. Also, I'd much rather encourage people to use certs properly than not and not everyone can afford a decent cert (the free ones all have limitations). Using a self-signed root cert is a great way to minimise management of the certs without loosing security when you can't afford a 3rd party cert. – Julian Knight May 30 '17 at 13:28
  • Thank you for comprehensive answer! Almost all is clear, except this sentence: "You have to take care though, if you plan or need to rollover the server's certificate, since that will become more complicated without using a trusted issuer certificate.". Can you explain this? – don-prog May 31 '17 at 4:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.