How do Client-specific keys and Certificates work?

Question

I have clients that communicates with my server. Clients sends it unique id (guid) to server with its request over a secure https channel. Also to increase security I use my own private-public key pair to encrypt requests & responses.

If someone find this public key (it comes with client software) and reverse-engineer the software I think they can send handmade requests with a custom id. I want to prevent this kind of attacks. I have couple of questions:

• Is generating private-public key pair for each client is a good practice? Since every client sends it's requests with their own public key, it will be easy to detect this kind of anomalies.
• Is it possible to give clients certificates that identifies only them? I see this client certificate thing everywhere but there is no clear explanation. Can you guys explain me how client certificates works? I think this is what I need but I have no idea about it.

Answer 1

If you want to authenticate a client to your server, you will need a private key for each client.

The usual HTTPS method (TLS) uses only one certificate to authenticate a server. The server has his public key published and signed by some authority, the client verifies the certificate and the authority signature of the certificate, then the client is sure to communicate with the right server, since only this server can sign the communication with his own (corresponding) private key.

Usual HTTPS method only authenticate the server.

If you want the client to be authenticated as well, they need their own private/public key-pair. After having authenticated the server, the client will send their public key and the server can then check the certificate against a local database, or a more global infrastructure if the certificates (of the clients) are signed by an authority.

Other parts of the HTTPS protocol support client authentication in this way.