In a secure deployment, there will be clients, services and certificate authorities. Each of these has public and private keys and certificates. It is important that private keys be kept private, and that public keys are made available. The diagram below shows which parties have with keys and certificates:

Diagram of sites, keys, CAs and certificates

Each party has a private key, which they generate themselves. Each party keeps their private key secret from everyone else. Each private key has a corresponding public key, which is given out freely. A message encrypted using a public key can only be read using the corresponding private key. This allows the client to send a message that only the server can read.

A message signed with a private key can be checked using the corresponding public key. If the message has been changed after signing then the check will fail. This allows the server to confirm that the message was really sent by the client.

As shown in the diagram, there are three public-private key-pairs (one for each party). The client uses a copy of the server's public key to encrypt the message, and its own private key to sign it. The server uses a copy of the client's public key to check the signature, and its own private key to decrypt it.

This is very secure, provided that both parties can get the required public keys. Although it doesn't matter if anyone else gets hold of the public keys, it does matter that they have the correct public keys. If an attacker gives the server their public key, pretending to be the client, then the server will accept messages sent by the attacker. Likewise, if the client wants to send a message to a server, but uses the attacker's public key instead of the server’s public key, then the client will send messages that the attacker can read.

To prevent this, the public keys come with a certificate giving the identity of the owner of the private key. The key and certificate bundle is signed by a certificate authority to confirm that the details are correct. The effect of this is that each party only needs to get the CA's public key by some trusted mechanism, and can use that to verify any other keys.

The diagram above shows only one CA. In more complicated situations, the client and server might have their certificates signed by different CAs. In that case, each must trust the CA that signed the other party's certificate. Also, the diagram only shows the request message. The response is signed and encrypted by the service and checked and decrypted by the client in a similar manner.