The SSL protocol is implemented on top of the TCP/IP protocol. From an endpoint view it also has the same type of connections as that protocol, almost always created by calls to socket interface functions listen, accept and connect. The endpoints are servers and clients.

A serverlistens for connections on a specific address and port. This is done once. The server then accepts each connections on that same address and port. This is typically done indefinitely many times.

A client connects to a server on a specific address and port. For each purpose this is done once.

For a plain TCP/IP connection the establishment of a connection (through an accept or a connect) is followed by data transfer between the client and server, finally ended by a connection close.

An SSL connection also consists of data transfer and connection close, However, the data transfer contains encrypted data, and in order to establish the encryption parameters, the data transfer is preceded by an SSL handshake. In this handshake the server plays a dominant role, and the main instrument used in achieving a valid SSL connection is the server's certificate. We consider certificates in the next section, and the SSL handshake in a subsequent section.

A certificate is similar to a driver's license, or a passport. The holder of the certificate is called the subject. First of all the certificate identifies the subject in terms of the name of the subject, its postal address, country name, company name (if applicable), etc.

Although a driver's license is always issued by a well-known and distinct authority, a certificate may have an issuer that is not so well-known. Therefore a certificate also always contains information on the issuer of the certificate. That information is of the same type as the information on the subject. The issuer of a certificate also signs the certificate with a digital signature (the signature is an inherent part of the certificate), which allow others to verify that the issuer really is the issuer of the certificate.

Now that a certificate can be checked by verifying the signature of the issuer, the question is how to trust the issuer. The answer to this question is to require that there is a certificate for the issuer as well. That issuer has in turn an issuer, which must also have a certificate, and so on. This certificate chain has to have en end, which then must be a certificate that is trusted by other means. We shall cover this problem of authentication in a subsequent section.

An encryption algorithm is a mathematical algorithm for encryption and decryption of messages (arrays of bytes, say). The algorithm as such is always required to be publicly known, otherwise its strength cannot be evaluated, and hence it cannot be used reliably. The secrecy of an encrypted message is not achieved by the secrecy of the algorithm used, but by the secrecy of the keys used as input to the encryption and decryption algorithms. For an account of cryptography in general see .

There are two classes of encryption algorithms: symmetric key algorithms and public key algorithms. Both types of algorithms are used in the SSL protocol.

In the sequel we assume holders of keys keep them secret (except public keys) and that they in that sense are trusted. How a holder of a secret key is proved to be the one it claims to be is a question of authentication, which, in the context of the SSL protocol, is described in a section further below.

The main purpose of the handshake performed before an an SSL connection is established is to negotiate the encryption algorithm and key to be used for the bulk data transfer between the client and the server. We are writing the key, since the algorithm to choose for bulk encryption one of the symmetric algorithms.

There is thus only one key to agree upon, and obviously that key has to be kept secret between the client and the server. To obtain that the handshake has to be encrypted as well.

The SSL protocol requires that the server always sends its certificate to the client in the beginning of the handshake. The client then retrieves the server's public key from the certificate, which means that the client can use the server's public key to encrypt messages to the server, and the server can decrypt those messages with its private key. Similarly, the server can encrypt messages to the client with its private key, and the client can decrypt messages with the server's public key. It is thus is with the server's public and private keys that messages in the handshake are encrypted and decrypted, and hence the key agreed upon for symmetric encryption of bulk data can be kept secret (there are more things to consider to really keep it secret, see ).

The above indicates that the server does not care who is connecting, and that only the client has the possibility to properly identify the server based on the server's certificate. That is indeed true in the minimal use of the protocol, but it is possible to instruct the server to request the certificate of the client, in order to have a means to identify the client, but it is by no means required to establish an SSL connection.

If a server request the client certificate, it verifies, as a part of the protocol, that the client really holds the private key of the certificate by sending the client a string of bytes to encrypt with its private key, which the server then decrypts with the client's public key, the result of which is compared with the original string of bytes (a similar procedure is always performed by the client when it has received the server's certificate).

The way clients and servers authenticate each other, i.e. proves that their respective peers are what they claim to be, is the topic of the next section.

As we have already seen the reception of a certificate from a peer is not enough to prove that the peer is authentic. More certificates are needed, and we have to consider how certificates are issued and on what grounds.

Certificates are issued by certification authorities (CAs) only. They issue certificates both for other CAs and ordinary users (which are not CAs).

Certain CAs are top CAs, i.e. they do not have a certificate issued by another CA. Instead they issue their own certificate, where the subject and issuer part of the certificate are identical (such a certificate is called a self-signed certificate). A top CA has to be well-known, and has to have a publicly available policy telling on what grounds it issues certificates.

There are a handful of top CAs in the world. You can examine the certificates of several of them by clicking through the menus of your web browser.

A top CA typically issues certificates for other CAs, called intermediate CAs, but possibly also to ordinary users. Thus the certificates derivable from a top CA constitute a tree, where the leaves of the tree are ordinary user certificates.

A certificate chain is an ordered sequence of certificates, C1, C2, ..., Cn, say, where C1 is a top CA certificate, and where Cn is an ordinary user certificate, and where the holder of C1 is the issuer of C2, the holder of C2 is the issuer of C3, ..., and the holder of Cn-1 is the issuer of Cn, the ordinary user certificate. The holders of C2, C3, ..., Cn-1 are then intermediate CAs.

Now to verify that a certificate chain is unbroken we have to take the public key from each certificate Ck, and apply that key to decrypt the signature of certificate Ck-1, thus obtaining the message digest computed by the holder of the Ck certificate, compute the real message digest of the Ck-1 certificate and compare the results. If they compare equal the link of the chain between Ck and Ck-1 is considered to unbroken. This is done for each link k = 1, 2, ..., n-1. If all links are found to be unbroken, the user certificate Cn is considered authenticated.