What is the proper behavior by an SSL/TLS client when it receives a Certificate Request message that has an empty DN list?
Here are two possibilities that seem natural: 1) Send back an empty Certificate message 2) select (or prompt user to select) a certificate from among all possible certificates
Is there a single correct behavior, or is either option OK? My goal is to provide a certificate in my code (.Net, WCF) to the server, and I'm trying to determine whether I need to make changes on the client side to override the seemingly default behavior of not sending the cert or if I need to make changes on the server side to actually send the DN list.
It appears that the browser will choose option 2, but my code using WCF and .Net is using option 1. I am able to select the certificate from the store, but it is not being sent in the TLS handshake.
The TLS 1.0 and 1.2 specs (RFCs 2246 and 5246) don't seem to provide any guidance on this situation.
This is actually an area where the TLS 1.0 specification and TLS 1.1/1.2 differ.
In particular, the following was added to Section 7.4.4 (Certificate Request) in TLS 1.1:
If the certificate_authorities list is empty then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary.
In my experience (at least with browsers and Java/JSSE), this also worked in practice for SSLv3 and TLS 1.0, even if nothing was said about the empty list.
It's still at the discretion of the implementation to choose what to do ("[...] may send any [...]").
In any case, even with a non-empty CA list, when multiple client certificates match the CA conditions, a choice would need to be made, automatically or via the UI. This is also implementation dependent, and may be customised depending on the framework.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With