Search code examples
authenticationsslclientx509

TLS client authentication


Does the TLS (v1.1, 1.2 etc) or X.509 standards dictate how the client and server need to negotiate the client authentication certificate?

Specifically, I am dealing with a case where the Server sends down a bunch of (about five) certificate authorities in it's Certificate Request message like so:

*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
<CN=AA, DC=BB, DC=cc, DC=dd>
<CN=EE, DC=FF, DC=gg, DC=hh>
<CN=II, DC=JJ, DC=kk, DC=ll>
<CN=MM, DC=NN, DC=oo, DC=pp>

The client keystore has multiple client certificates that match (are issued by) one of these Cert Authorities received from the server.

I see my client selecting and using the first certificate (among the many) in the keystore that match the server's trusted CAs. However, the server will not accept this certificate. The certificate the server will accept is present in the client keystore, but it's just not the first one in the list of certs that matched the server's certificate request criteria. The server terminates the connection and sends no alerts.

Now I have two questions:

  1. Is either my client or the server misbehaving?

  2. Do TLS specifications have anything to say about Client-Server trying out all the matching client certificates before giving up on the connection?

In case TLS specs say nothing about this - how is this problem best addressed in general? Is adding intelligence to the client (say, through specifying the alias or some other such selection mechanism) the only way to address this issue? Why would TLS protocol not handle this on it's own ?

I have read through the TLS specifications and whatever X.509 information I could trawl on the net (admittedly not exhaustively) but I didn't get clear information on this.


Solution

  • Is either my client or the server misbehaving?

    Given your description the server requests a certificate signed by a specific CA and the client sends such a certificate but the server then does not accept it. The reason might be that the certificate is wrong, has insecure signature, is expired, revoked or similar in which case the client should not have send it. Or it might be that the server is wrong in not accepting a perfectly valid certificate. It is impossible to tell from your description which of these is the case.

    Do TLS specifications have anything to say about Client-Server trying out all the matching client certificates before giving up on the connection?

    No, it expects the client to send a valid certificate which matches the requirements of the server on the first try and expects that the server will accept this valid certificate. A common behavior for a client is to ask the user which certificate should be used if multiple match the advertised requirements of the server.