Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Say that we have a client / server solution (written in .NET). If we want to use a certificate for the TCP communication, is it enough to use one function/service certificate to encrypt communication both from client to server and from server to client? Or do I have to install one certificate for the client as well to get encrypt in both directions?

One thing is that a certificate ensure who you are talking with another is to encrypt the communication.

share|improve this question

First, you don't "encrypt with a certificate". You encrypt with a protocol which may or may not use certificates for public key distribution. The most commonly used protocol for protecting bidirectional data channels is SSL (now known as TLS). In SSL, there is a client and a server, which need not correspond to the "client" and "server" at the TCP level: the SSL "client" is the one who begins the SSL handshake, i.e. who sends the ClientHello message.

In SSL, the server normally shows its public key as part of a certificate. The client validates the server's certificate (it checks that it is issued by a trusted CA) and verifies that the certificate indeed contains the intended server name. This means that the client has some guarantee that it is talking to the right server. On the other hand, the server does not know who the client is; the server just has the guarantee that it is talking with the same client during the whole connection.

If the server must know who it is talking to, then some sort of client authentication must be applied. SSL supports client certificates for that. Another method, very often employed in a Web context, is to have the client show some credentials (a login and a password) inside the SSL tunnel (since the client has some guarantee that it talks to the right server, then it can send the password to the server without fearing interception by an attacker).

SSL also supports some certificate-less connections, e.g. the PSK cipher suites, in which client and server authenticate each other with regards to a shared secret value; if, in your situation, you can arrange for client and server to know a common secret key, then this will avoid all the certificate business. If the shared secret is a low-entropy value (e.g. it is a "password" that a human user will be able to remember and will accept to type occasionally), then SRP cipher suites are the way to go. PSK or SRP support in .NET may require some extra libraries, though (e.g. OpenSSL bindings for .NET).

share|improve this answer
Thanks! Nice explanation! I do however have some follow up questions : 1. So you could use only 1 certificate to encrypt communication in both directions the only drawback is that one of the actors will not be authenticated, 2: Could I use certificate just to authenticate actors and when that is done use a regular connection for example getting better speed? – SnowJim Apr 11 '13 at 12:44
With SSL, the asymmetric cryptography (which uses the public key from the certificate) is used only at the start (during the "handshake") and the rest of the connection uses only symmetric encryption, which is fast (an old anemic PC will be more than fast enough to do SSL at 100 Mbits/s). Don't surmise speed issues until you have duly measured them in your situation. – Thomas Pornin Apr 11 '13 at 12:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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