Clients need to trust the servers they are connecting to, in order to avoid sending data, such as passwords, to unauthorized parties. They need to verify the identity of the server. In other terms: The server authenticates itself to the client.
Server Authentication During the TLS Handshake
When a client connects to a server using the TLS protocol, such as HTTPS, the client verifies the server's identity during the TLS handshake. The following steps describe this process in a drastically simplified manner. They do not aim to reflect the real procedure of the TLS protocol. Instead, they help you understand the process.
- The server sends its server certificate to the client containing (among others) the server name and the public encryption key.
- The client checks the certificate (its validity period; if it was issued by a certificate authority trusted by the client and that the signature is valid; and if it matches the server name, of course).
- The client encrypts a random number with the server's public key, which needs to be decrypted by the server with its private key to prove the possession of the corresponding private key.
If one of these steps fails, the connection is not established. Common reasons for that are as follows:
- The server certificate has expired.
- The server name mentioned in the certificate does not match the hostname that the client tries to connect to.
- The client does not trust the certificate authority that issued the server certificate or can't verify the certificate chain due to missing entries in the client's trust store.
Note
Clients need to maintain trust lists, which means storing the certificates of trusted certificate authorities (CAs), to be able to verify the certificate chain of a server. These lists must at least contain certificates of root CAs, but can also contain intermediate CAs. Intermediate certificates are typically sent from the server together with the server certificate so that clients only need to know about the corresponding root CA to verify the certificate chain.The following video visualizes the process. Keep in mind that the video also shows a drastically simplified version of the process for demonstration purposes!
The video focuses on the server authentication as part of the TLS handshake. If the server requires the client to authenticate as well with a client certificate, this process is carried out a second time in reverse order. In this case, the client sends its certificate to the server and the server verifies it. This is also called mutual authentication. Certificate-based authentication is explained in the next lesson.
With features such as encryption and the authentication of the communication counterpart, the TLS protocol strongly helps to protect communication against so-called Man-In-The-Middle (MITM) attacks, where an attacker tries to intercept all messages between the client and the server and possibly inject new ones. Without trusted certificate authorities that issue and sign the certificates, an attacker could simply generate its own certificates and impersonate the identity of the communication partner.