5

I am trying to create an SSL Socket Server/Client between .NET and Java. In this case, my SSL Socket Server will run in .net and the client runs in Java under Linux. My problem is that the connection fails during the handshaking, specifically when the server request a certificate from the client, the client is unable to send something back and the connection fails.

In .net I am using sslStream to establish the connection and on Java I am using the standard SSLSocket. Some code snippets are below, but this is what I have so far:

On the server side (Windows), I have a private certificate in the Personal/Certificates folders under MMC. I have a public certificate from the client in the Trusted People/Certificates. Both certificates were issued by the same CA. The certificate chain for both certificates have multiple levels, but it is the same for both. The root level certificate in the chain is also installed in the trusted Certification Authorities/Certificates folder.

On the client side (Linux), I have a keystore that contains the private certificate that matches the public certificate installed at the server. I have a trust store that contains the public certificate from the server, matching the server's private one.

On the server side (.net) I am using a Socket that does an asynchronous read and then it gets wrapped into an SSLStream, the code snippet is like this:

NetworkStream ns = new NetworkStream(socket, false);
SslStream ssl = new SslStream(ns, true);
ssl.AuthenticateAsServer(serverCertificate, true, SslProtocols.Default, true);

The client code is pretty much standard code:

SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
InetAddress addr = InetAddress.getByName(servername);
SSLSocket socket = (SSLSocket) factory.createSocket(addr,port);
socket.setUseClientMode(true);
socket.setNeedClientAuth(true);
socket.setWantClientAuth(true);
socket.startHandshake();
os = new DataOutputStream(socket.getOutputStream());
is = new DataInputStream(socket.getInputStream());
byte[] outBuf = new byte[50];
os.write("SEND SOMETHING".getBytes("UTF-8"));
is.read(outBuf);

In java I have set the proper varialbes to point to the trust and key store with their password.

Now, following the standard SSL Handshake, this is what happens:

  • ClientHello
  • ServerHello
  • Server sends public certificate
  • Client matches the public certificate with the one on the trust store
  • Server sends the Certificate request
  • With the certificate request the server sends a list of valid CAs, on this list only the my root CA is sent (among a long list of other well known CAs.).
  • Client certificate is null.
  • Server receives a null certificate from the client, thus closes the connection.

And that is it, the client won't send a valid certificate back to the server. I have some questions on this:

Has anybody experienced something like this? Regarding that list of CAs sent by the server (Windows), How does .net determine what to send to the client? Is there a way to modify that list? Do I need to send the all the authorities in the chain used to sign my certificate in that list of CAs? or is the Root one enough?

Am I missing something on either side of my code?

Any help will be greatly appreciated it. In

Bruno
  • 119,590
  • 31
  • 270
  • 376
Jorge Varona
  • 195
  • 2
  • 8
  • The problem was with the certificate at the client side. The certificate did not contain the full chain, hence when the server sent the list of valid CAs including only the root CA, the client was unable to find a matching certificate within the store. We re-imported the certificate with the full chain into the key store and everything started working fine. – Jorge Varona Mar 17 '12 at 12:07
  • So how did you get it to work on the JAVA end? Any information would be greatly appreciated. Thanks – Mr.Noob Feb 19 '15 at 15:04
  • 1
    @Mr.Noob Sorry for the long, long delay on this response. On the Java side it is the same issue. The certificate needs to have the full CA chain, because the validations is done against the chain. – Jorge Varona Dec 03 '15 at 17:30

1 Answers1

2

The following two statements are useless on the client side (although they shouldn't hurt):

socket.setNeedClientAuth(true);
socket.setWantClientAuth(true);

The fact that you see the Certificate Request message and the Client Certificate message shows that the server is configured properly.

The most likely cause that comes to mind for the absence of certificate in the client certificate message is that the keystore (on the client side) might not be configured properly. You may be interested in this answer to make sure that your client key store is configured properly. More specifically, you need to make sure that the private key for your client certificate was imported in the same alias as the certificate chain (and that it's the chain going back to a CA advertised in the Certificate Request message).

(Regarding the rest of your question, I'm not sure how to modify the CA list sent by the server when using SslStream in C#. This earlier question would seem to suggest there is no solution, although newer versions of .Net may have addresses the issue since this question was asked. I haven't been able to find anything that would do it by looking at the SslStream API documentation and related classes, but this doesn't mean it doesn't exist.)

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • The CA list sent by the server comes from its truststore unless there is an override, e.g. in Java terms, an override of `X509TrustManager.getAcceptedIssuers()`. – user207421 Mar 16 '12 at 01:38
  • @EJP, I've edited to clarify, sorry. I knew that from the Java side. What I don't know is .Net's `SslStream`'s equivalent (this is a C# server). – Bruno Mar 16 '12 at 01:44
  • surely it uses the Windows truststore, same as IE's? – user207421 Mar 16 '12 at 05:24
  • @EJP, I guess so. In [`SslStream`](http://msdn.microsoft.com/en-us/library/ms145057.aspx), from a server point of view, [`RemoteCertificateValidationCallback`](http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback.aspx) seems to be the equiv. of Java's `X509TM.checkClientTrusted` and [`LocalCertificateSelectionCallback`](http://msdn.microsoft.com/en-us/library/system.net.security.localcertificateselectioncallback.aspx) seems to be the equiv. of the key manager . I'm not sure where to find the equiv. of `getAcceptedIssuers()` in this API. – Bruno Mar 16 '12 at 11:01
  • Thank you for your responses. I was able to find the solution. The problem was on the lines to the posted links. I posted the full answer below. – Jorge Varona Mar 16 '12 at 15:28