3

I am currently working on a SSL client in Java and need to establish a https connection with a third party server which requires client authentication. The server guys have given me a trusted root CA cert that is used to sign both client as well as server certificates. I have put this cert in the truststore on my side. The server folks also have this root CA cert which they use to verify client certificates.

When I try to establish a SSL connection the server I see that the handshake goes through fine when server sends it's cert and my client is able to verify it successfully. But as part of the 'Certificate Request' message, the server DOES NOT return any root CA cert in the 'Cert Authorities' parameter. Due to this my client does not send the client cert back to the server and the handshake fails.

I am writing standard Java code with WSDL stubs. I am leveraging the wsdl stubs generated by wsdl2Java ant task.

So My question is: Can I make my java client send a pre-set client certificate back to the server even when the server sends an empty 'Cert Authorities' list when it requests the client authentication. (I read the TLS RFC and I see that its legal for a server to send an empty list like this in which case the client may send back any certificate it sees fit. I am trying to achieve exactly the same behavior).

user207421
  • 305,947
  • 44
  • 307
  • 483
mandar bapaye
  • 51
  • 1
  • 2

3 Answers3

2

Sorry for replying to this age old post, but I couldn't resist.

I have seen this kind of handshakes work just fine:

according to javax.net.debug=all

*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Supported Signature Algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA256withRSA, Unknown (hash:0x4, signature:0x2), SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3, signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA
Cert Authorities:
<Empty>
*** ServerHelloDone
matching alias: our_client_cert_alias
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=

But it might depend on your HTTP client library and how it handles SSL/TLS (re)negotiation. This was using Java 8 and http://spray.io/documentation/1.2.4/spray-client/

JohannesB
  • 2,214
  • 1
  • 11
  • 18
1

There's no point in this. The server still won't accept it. At least it shouldn't accept it, and if it is using any of SSL implementations in common use it won't accept it. And it isn't at all likely that they've tweaked their own SSL implementation.

The problem is at the server end. It is misconfigured. You can't fix it at the client end. It should be sending you that root CA cert, or one of its signers, in the CertificateRequest message.

EDIT This answer applies to TLS 1.0. It is obsoleted by TLS 1.1 and successors.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Hi EJP - Thanks for the reply. I am dealing with Teradici virtualized devices here which host the https server and they DO NOT return the cert auth list for sure. They have indicated that if I send them the client-cert which they have supplied to me, then the server would be able to successfully verify it (as it is signed by their own root CA). But unfortunately right now, I am not even able to send the client-cert back to them. Could you please let me know if there is a way to do this ? – mandar bapaye May 28 '13 at 23:05
  • 1
    There isn't. You would have to hack your local SSL implementation. It's a bug or misconfiguration at their end and it is up to them to fix it. No ifs or buts about it. They don't appear to know as much about SSL as they should if they are putting it back onto you. – user207421 May 28 '13 at 23:56
  • Thanks EJP. I will talk to those guys again :) – mandar bapaye May 30 '13 at 00:15
  • This answer is completely wrong, it is perfect fine for server to send back a empty Cert Authorities[] in Certificate Request, and lots of http client implementation will just send whatever key you set for this http client. I am debugging unrelated ssl issue and fount this question, just clarify this so it won't confusing more ppl in the future. – Leo Jun 11 '21 at 04:24
  • @Leo HTTP clients are not implementations of TLS, and keys are not certificates. Be precise. – user207421 Jun 12 '21 at 02:22
  • @user207421 yes, i should say tls client , and "whatever cert you set", not key. just notice your edit, if your answer holds true for TLS 1.0, then I apology for saying this answer is complete wrong. Just outdated, which is understandable for an answer from 8 years ago. And now with the edit it is correct. – Leo Jun 14 '21 at 16:09
1

We encountered similar issue, and kind of interesting, the library we use is spring-ws and spring-ws-support, there you can create a HttpsUrlMessagenSender bean to make soap calls, by setting custom KeyStoreFactoryBean, you can set your jks keystore(client cert) location. But we got the same issue mentioned here.

But if we use default behavior(no HttpsUrlMessagenSender bean), and passing the keystore via java.net.ssl.keyStore it works, with empty Cert Authority list, it sends the client cert anyway.

It seems to me that the jvm arg triggered some behavior that is different. Some software even has flag to deal with this http://techcommunity.softwareag.com/web/guest/pwiki/-/wiki/Main/Debugging+TLS+SSL+connections+in+Integration+Server

gatekeeper
  • 11
  • 1