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.
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).
