10.5.7 The CertificateVerify message
The CertificateVerify message provides explicit proof that the sender—either client Bob or server Alice—indeed has the private key corresponding to its certificate. Moreover, the CertificateVerify message allows you to verify the integrity of the TLS handshake up to this point. Listing 10.6 shows the structure of the CertificateVerify message:
Listing 10.6: Structure of the CertificateVerify message
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
The algorithm field in Listing 10.6 holds the signature algorithm used to generate the signature. The content covered by the signature includes the TLS handshake context and the certificate.
The signature is computed over a concatenation of the following data:
- A string consisting of 64 bytes having a value of 32
- The TLS 1.3, server CertificateVerify string for server Alice’s signature and the TLS 1.3, client CertificateVerify string for client Bob’s signature
- A single byte having value 0 that acts as a separator
- The content to be signed
The context string secures TLS against cross-protocol attacks by providing a way to differentiate between the signatures generated in different contexts.
Server Alice sends the CertificateVerify message when she authenticates herself to client Bob using a certificate. Client Bob sends CertificateVerify whenever he authenticates himself using a certificate. If sent, the CertificateVerify message is transmitted immediately after the Certificate message and immediately before the Finished message.
For example, if the transcript hash consists of 32 bytes having the value 01, the content covered by the signature in server Alice’s CertificateVerify message reads like this:
2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966
79
00
0101010101010101010101010101010101010101010101010101010101010101
The sender of the CertificateVerify message computes the signature by taking the following data as input:
- The data covered by the signature
- The private key corresponding to the public key in the sender’s certificate transmitted in the previous TLS message
When server Alice sends the CertificateVerify message, the digital signature algorithm Alice uses must be one of the algorithms that client Bob specified in his signature˙algorithms extension.
When client Bob sends the CertificateVerify message, the digital signature algorithm must be among those specified in the supported˙signature˙algorithms field of the signature˙algorithms extension in the CertificateRequest message.
The above illustrates how TLS addresses potential compatibility issues in a heterogeneous environment where different clients must communicate with different servers, with the endpoints likely supporting different digital signature algorithms.
The receiver of the CertificateVerify message verifies the digital signature. The verification process takes the following data as input:
- The data covered by the signature
- The public key in the certificate from the corresponding Certificate message
- The digital signature in the received CertificateVerify message
If the verification is not successful, the receiver terminates the TLS handshake and sends a decrypt˙alert alert to the other communicating party.