10.5 Digital certificates in TLS

Now we will take a look at how certificates are handled within the TLS handshake protocol. We start by discussing TLS extensions, which provide a way to transport data in request-response type message exchanges within TLS. The rest of the section is broadly organized according to the TLS extensions dealing with digital certificates and certification authorities.

10.5.1 TLS extensions

Some TLS messages include the tag-value data structure shown in Listing  10.1 and referred to as an extension. The extension˙type field specifies the type of the extension, and the extension˙data field stores the corresponding data.

Listing 10.1: Data structure of a TLS extension

struct {
   ExtensionType extension_type;
   opaque extension_data<0..2^16-1>;
} Extension;

Typically, TLS extensions are used in a request-response message exchange: client Bob sends an extension request in his ClientHello message, and server Alice replies with an extension response in her ServerHello, EncryptedExtensions, HelloRetryRequest, or Certificate message.

If server Alice sends an extension request in her CertificateRequest message, client Bob may respond with a Certificate message.

10.5.2 Encrypted extensions

In TLS 1.3 handshake, server Alice sends the EncryptedExtensions message immediately after her ServerHello message. At this point, Alice and Bob have agreed on a secret and have subsequently derived a shared key. The EncryptedExtensions message is the first encrypted message in the TLS handshake. The data structure is shown in Listing 10.2.

Listing 10.2: TLS encrypted extension data structure

struct {
   Extension extensions<0..2^16-1>;
} EncryptedExtensions;

10.5.3 Certificate request

If server Alice authenticates herself to client Bob using a certificate, she may request Bob to present his certificate too. This request must be sent directly after EncryptedExtensions and the corresponding message has the structure shown in Listing 10.3.

Listing 10.3: Server Alice’s certificate request

struct {
   opaque certificate_request_context<0..2^8-1>;
   Extension extensions<2..2^16-1>;
} CertificateRequest;

The preceding is a good illustration of how optional interaction between communicating parties can be added to a cryptographic protocol to further improve security, if this is desired by Alice and Bob. Requiring client Bob to also prove his identity, in this case using a digital certificate, results in a mutual authentication where both client Bob as well as server Alice can verify each other’s identity and so know whom they are communicating with.