TLS communication between the client and server always begins with a so-called handshake. This handshake permits authentication of the server and agreement to be reached on the encryption method and key that are to be used.
With every handshake the server must authenticate itself to the client by means of public key encryption. The server can also request the client to authenticate itself (also by means of public key encryption). However, this is generally not done.
Expressed in simplified form, the following steps are required for the TLS handshake:
The client sends a list of the encryption methods (cipher suites) it supports to the server.
The server selects a method from this list and returns this to the client, together with the server’s own certificate containing the server’s public key.
The client checks whether the server certificate has already been signed by a CA whose certificate is present at the client end and which the client thus trusts implicitly. The client also checks whether the certificate was issued for the server to which it wants to set up the connection. Here the client checks
whether the CN (Common Name) of the subject is the same as the server’s FQDN (Fully Qualified Domain Name), or
whether the DNS part of the X.509v3 Subject Alternative Name is the same as the server’s FQDN.
With the aid of the server’s public key the client encrypts a PreMaster Secret and sends this to the server. From the PreMaster Secret and the random numbers exchanged in the preceding steps the client and server then calculate the keys which are required for the various encryption and MAC algorithms.
Depending on the configuration, the server requests a certificate from the client in the context of the handshake. The server checks whether this certificate was signed by a CA it rates as trustworthy. No more detailed checks of the client certificate are performed within interNet Services.