2

When testing our c# application with a service from a new supplier our request was denied because the client certificate was not send.

Network traffic with a service where our application is known to work with shows us this:

Client Hello
Server Hello, Certificate, Certificate Request, Server Hello Done
Certificate, Client Key Exchange, Certificate Verify...

The service asks the client for a certificate and our client sends it.

In the situation where the certificate is not send traffic looks like this:

Client Hello
Server Hello, Certificate, Server Hello Done
Client Key Exchange, ...

The service does not ask for a certificate and the client does not volunteer one.

Question is: Can a client send a certificate without being asked for one?

No, according to this: https://stackoverflow.com/questions/31200348/mutual-ssl-authentication-with-wcf-no-certificaterequest-and-certificateverify

By stating: A common confusion that I noticed while looking for a solution is that many people believe that the client can send the certificate if it has it, unchallenged. This is, of course, not the case - the server needs to ask for it first

Yes, according to this:https://stackoverflow.com/questions/49024391/when-do-i-need-negotiate-client-certificate-to-be-set-to-enabled#:~:text=The%20Negotiate%20Client%20Certificate%20setting,the%20web-server%20is%20negotiated.

By stating: *IIS has two ways to negotiate TLS: Where the client sends the client certificate in the initial request. This is useful when all resources on the server require TLS client authentication.

Where the client doesn't send the client in the initial request, but later after IIS performs a TLS re-negotiation. This is useful when only some resources require TLS client authentication.*

Now which is right?

1 Answer 1

3

The client will only send a client certificate when requested by the server. This CertificateRequest can be sent by the server in the initial TLS handshake. But it can also be sent in a later renegotiation (up to TLS 1.2) or post-handshake authentication (TLS 1.3). This is typically the case when only some resources on the server require client certificates and the requested resource is only known after the initial TLS handshake.

2
  • 1
    This changes in TLS 1.3: all renegotiation is gone, but there is an option for Post-Handshake (Client) Authentication, see rfc8446 4.6.2. (Also a separate operation for rekeying, which was formerly a purpose of renegotiation.) I don't know if IIS supports 1.3. Jul 28, 2020 at 3:59
  • @dave_thompson_085: Thanks, I've explicitly added post handshake authentication to the answer. Jul 28, 2020 at 4:04

You must log in to answer this question.

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