I was wondering, why the TLS 1.3 handshake employs two different 'messages' that compute an authentication code over the whole handshake. As far as I understand, the CertificateVerify "message" computes an asymmetric digital signature based on the certificate's signature algorithm, over the whole handshake. The finished message on the other hand employs a symmetric HMAC using the exchanged symmetric ephemeral keys to also compute a MAC over the whole handshake.
RFC 8446 phrases this as:
CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message. This message is omitted if the endpoint is not authenticating via a certificate. [Section 4.4.3]
Finished: A MAC (Message Authentication Code) over the entire handshake. This message provides key confirmation, binds the endpoint's identity to the exchanged keys, and in PSK mode also authenticates the handshake. [Section 4.4.4]
In my understanding, the authentication code is calculated over the message to avoid man-in-the-middle attacks. However, I do not understand why the complete handshake is authenticated twice with two different messages ( using two different algorithms and two different keys)? Wouldn't it be sufficient to solely use the asymmetric signature from the certificate over the complete handshake to authenticate the handshake and bind the symmetric keys to the identity?
Also, I think that if somebody would have tampered with the DH-Key exchange earlier, even the CertificateVerify message would not decrypt correctly, as the whole handshake is different. This would also mean that the symmetric key is bound to entity already with the CertificateVerify Message, and the Finished message is obsolete.
However, the designers of TLS 1.3 presumably have a much stronger cryptographic background than I do, so I was wondering where I was missing a security need for the finished message?
Thank you in advance.