Client Failing TLS 1.0 Handshake when CA List provided by Server

0
votes

We have a relatively old piece of hardware running a client application that has a requirement of making web service calls over TLS 1.0.

The server has many different clients, and so it supports TLS 1.0, 1.1, and 1.2. Therefore, when the server sends it's certificate, it's also alongside a list of CA's. The server is set so that the client can optionally provide a certificate, but it's not required. The issue is that as soon as the client sees a list of CA's, it is sending back a FIN/ACK (closing the connection).

This seems like incorrect behaviour. According to TLS 1.0 RFC https://www.rfc-editor.org/rfc/rfc2246#section-7.4.2

Note that a client may send no certificates if it does not have an appropriate certificate to send in response to the server's authentication request.

Presumably, the client is seeing the list of CA's and assuming that it's required to present a Certificate and outright failing because it does not have one. The client works when it is provided no CA list, which we can force by disabling TLS 1.1 and 1.2 on the server. Unfortunately, this is not an option in our production environment.

My question is whether the above conclusion is correct; should the client instead be responding with no certificate instead of closing the connection?

If so, I see a few options:

  • Create client certificate and install on each client device
  • Open a separate port on the Server to only allow TLS 1.0 to be used specifically for this client.
  • Support ticket to vendor for client device and hope they get it fixed or have a solution (doubt it)

We are leaning towards option 2, as it's the easiest solution for us to implement. If anyone has any other way for us to solve the problem, it would be much appreciated.

1
sslcertificatehandshake

1 Answers

2
votes

My question is whether the above conclusion is correct; should the client instead be responding with no certificate instead of closing the connection?

Yes. See RFC 2246 #7.4.6 Client Certificate:

This message is only sent if the server requests a certificate. If no suitable certificate is available, the client should send a certificate message containing no certificates.

Perfectly clear.

If so, I see a few options:

  • Create client certificate and install on each client device

Probably the best solution but it's proobsbly also the most expensive.

  • Open a separate port on the Server to only allow TLS 1.0 to be used specifically for this client.

I don't see why that should be necessary. The server should already know that he client is speaking TLS 1.0 from the first ClientHello message. I doubt that this option would change anything. If it does it would indicate something wrong with the server.

  • Support ticket to vendor for client device and hope they get it fixed or have a solution (doubt it)

I would definitely do that, whatever else you do. The vendor is violating RFC 2256 and is therefore issuing a useless product, and one that probably doesn't comply with its own specification (which will no doubt mention TLS 1.0).

We are leaning towards option 2, as it's the easiest solution for us to implement.

As I said above, I doubt it will actually fix it. I think you should engage the vendor's support channel.