"Dan Maharry" <dan.maha***@cit.coop> wrote in message
news:eLZw5NDRFHA.3544@TK2MSFTNGP12.phx.gbl...
> Hello,
>
> I recently inherited a .net server app that communicates with its clients
> over a secure channel using TSL to authenticate the clients before any
> conversation takes place. This was working fine against .NET and Java 1.2
> and 1.3 clients, but recently a problem appeared when one company upgraded
> their client to use Java 1.4. A colleague tracked the problem down to the
> following.
>
> It seems that in TLS, when the server requests a certificate from the
> client, it (the server) sends down a list of the distinguished names of
> root certificates which it trusts. The problem is that this list only
> contains about 60 certificates - although the server itself has around 165
> certificates in its 'Trusted Root Certificates' store. Most importantly,
> the certificate with the distinguished name <OU=Secure Server
> Certification Authority,O="RSA Data Security, Inc.",C=US> is not on this
> list - although it is installed on the server. The Java 1.4 client uses
> this root cert to back its client cert.
>
> It appears that a .NET client can be made to ignore this list and send a
> cert even though it doesn't know that the server can validate it. Java 1.2
> and 1.3 clients also ignore this list.
>
> Java 1.4 and 1.5 clients, on the contrary, seem to rely upon the list, and
> use it to find a certificate in one of their certificate stores that can
> trace its authority back to one of the specified roots. This is, of
> course, perfectly correct behaviour.
>
> This does mean that, when given a keystore containing a certificate and
> this list of root authorities, a Java SSL system will decide not to send a
> client certificate. This is the behaviour I've managed to produce using my
> own Java SSL cleint code and a stripped down .NET SSL server, with a lot
> of logging on the raw socket data. If the Java client has a certificate
> that traces its authority back to one of the listed root certificates,
> then it happily sends the certificate to the server. If it's absent then
> no certificate is submitted.
>
> Can anyone explain or help us to determine why our SSL stack won't send
> all the certificates it trusts in client handshaking, and correct this
> behaviour? We're some way out of our comfort levels now.
>
> Cheers, Dan

> Does the certificate trust list for your web site contain the correct root
> list?  (See
> http://support.microsoft.com/default.aspx?scid=kb;en-us;q313071&sd=tech if
> you're not sure how to verify or change this.)
>
>
> "Dan Maharry" <dan.maha***@cit.coop> wrote in message
> news:eLZw5NDRFHA.3544@TK2MSFTNGP12.phx.gbl...
>
>>Hello,
>>
>>I recently inherited a .net server app that communicates with its clients
>>over a secure channel using TSL to authenticate the clients before any
>>conversation takes place. This was working fine against .NET and Java 1.2
>>and 1.3 clients, but recently a problem appeared when one company upgraded
>>their client to use Java 1.4. A colleague tracked the problem down to the
>>following.
>>
>>It seems that in TLS, when the server requests a certificate from the
>>client, it (the server) sends down a list of the distinguished names of
>>root certificates which it trusts. The problem is that this list only
>>contains about 60 certificates - although the server itself has around 165
>>certificates in its 'Trusted Root Certificates' store. Most importantly,
>>the certificate with the distinguished name <OU=Secure Server
>>Certification Authority,O="RSA Data Security, Inc.",C=US> is not on this
>>list - although it is installed on the server. The Java 1.4 client uses
>>this root cert to back its client cert.
>>
>>It appears that a .NET client can be made to ignore this list and send a
>>cert even though it doesn't know that the server can validate it. Java 1.2
>>and 1.3 clients also ignore this list.
>>
>>Java 1.4 and 1.5 clients, on the contrary, seem to rely upon the list, and
>>use it to find a certificate in one of their certificate stores that can
>>trace its authority back to one of the specified roots. This is, of
>>course, perfectly correct behaviour.
>>
>>This does mean that, when given a keystore containing a certificate and
>>this list of root authorities, a Java SSL system will decide not to send a
>>client certificate. This is the behaviour I've managed to produce using my
>>own Java SSL cleint code and a stripped down .NET SSL server, with a lot
>>of logging on the raw socket data. If the Java client has a certificate
>>that traces its authority back to one of the listed root certificates,
>>then it happily sends the certificate to the server. If it's absent then
>>no certificate is submitted.
>>
>>Can anyone explain or help us to determine why our SSL stack won't send
>>all the certificates it trusts in client handshaking, and correct this
>>behaviour? We're some way out of our comfort levels now.
>>
>>Cheers, Dan
>
>
>