With client authentication the client sends the certificate after the client and server hello.

Is it possible to send it already with the client hello, so the server does not even answer with a hello but instead rejects the connection?

1 Answer 1


TL;DR: This is not possible with a standard conforming implementation.

The TLS 1.2 and TLS 1.3 standards clearly describe the sequence of communication inside the TLS handshake. A client certificate can not be send inside the ClientHello since the structure of the ClientHello record does not have a place for it. It is instead sent within a Certificate record, similar to how server certificates are sent. Only a Certificate record from the client is supposed to be sent only after the server explicitly requested it with a CertificateRequest. (see TLS 1.3 spec, sections CertificateRequest, and Certificate for the definition of this behavior)

Note that in order to prove that the client actually owns the certificate it needs to sign some challenge - and this signature (CertificateVerify) can be then checked by the server (see CertificateVerify). The challenge should not be set by the client itself since this would allow replay attacks. Therefore the challenge must at least in part be defined by the server - similar on how the same kind of challenge for the server certificate is partially defined by the client. To have this kind of input the client must have data from the server first, i.e. the CertificateVerify can not be send w/o an initial data exchange.

Even if the protocol allowed you to send a Certificate message along with your ClientHello, it would not save you round-trips on a successful handshake. This does not mean that the protocol could be designed in a way that the certificate is sent immediately but verified only later. This way the server could early reject a certificate which would be not acceptable no matter if the (later) validation failed or not. Only, the protocol is not designed this way. On reason might be that the server wants to notify the client which CA are acceptable so that the client can select the appropriate certificate. Other reason might be that using a valid but still wrong certificate is unlikely, so an optimization for this case is not actually needed.

  • Reasons for this choice? Wouldn't it be more efficient?
    – mait
    Jan 7, 2021 at 22:39
  • My guess: Client certificate is not always needed. So why send more data over the wire unless required?
    – Limit
    Jan 7, 2021 at 22:51
  • @mait: see updated answer. Jan 7, 2021 at 22:55
  • Would these challenge replay attacks still matter with the potentially upcoming encrypted client hello?
    – mait
    Jan 7, 2021 at 23:17
  • 1
    +1. Another reason to put Certificate later in handshake: TCP congestion window gets larger with each round-trip. As certificates can be fairly large, you want the cert as late in the protocol as possible to avoid packet fragmentation; network engineers consider it rude for the client to send a large amount of data before the server has had a chance to respond. Jan 7, 2021 at 23:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .