No client certificate available when consuming webservice on a self-signed certificate server

,
1

This issue is on WM9.0 Mediator but I believe this is a common problem for all kind of Integration Server.

We have defined a virtual service on CentraSite and deployed it to Mediator. The service end point is an HTTPS URL of an external application server (not SoftwareAG). Authentication to this service is being done with X509 SSL Client Certificate authentication.

We have done the tests on 2 different server certificate settings:

  1. The server certificate is signed by 3rd-party CA.
    • The CA that has signed the server certificate is added to the Mediator IS TrustStore.
    • The Mediator IS server certificate (in SSL Key) is valid for client authentication.
    • The SSL handshake and the webservice call go fine:
      ----- user is authenticated vs. the returned client certificate
      ----- service is executed
      ----- everything is fine
  2. The server certificate is self-signed.
    • The self-signed certificate itself is added to the Mediator IS TrustStore.
    • The Mediator IS server certificate (in SSL Key) is valid for client authentication. (no change)
    • The SSL handshake goes fine until the server requests the client certificate. At this point, the SSL Debug lines reference the following problem: No client certificate available, sending empty certificate message…

Below are the SSL Debug lines when server certificate is 3rd-party CA signed:

jvm 1 | ssl_debug(2308): Starting handshake (iSaSiLk 3.03)…
jvm 1 | ssl_debug(2308): Sending secure renegotiation cipher suite
jvm 1 | ssl_debug(2308): Sending v2 client_hello message, requesting version 3.1…
jvm 1 | ssl_debug(2308): Received v3 server_hello handshake message.
jvm 1 | ssl_debug(2308): Server selected SSL version 3.1.
jvm 1 | ssl_debug(2308): Server created new session 3C:59:39:8D:D9:AB:69:31…
jvm 1 | ssl_debug(2308): CipherSuite selected by server: TLS_RSA_WITH_AES_128_CBC_SHA
jvm 1 | ssl_debug(2308): CompressionMethod selected by server: NULL
jvm 1 | ssl_debug(2308): Received certificate handshake message with server certificate.
jvm 1 | ssl_debug(2308): Server sent a 1024 bit RSA certificate, chain has 2 elements.
jvm 1 | ssl_debug(2308): Received certificate_request handshake message.
jvm 1 | ssl_debug(2308): Accepted certificate types: RSA, DSS
jvm 1 | ssl_debug(2308): Accepted certificate authorities:
jvm 1 | ssl_debug(2308): cn=MyCompany Root CA,o=BLOU
jvm 1 | ssl_debug(2308): Received server_hello_done handshake message.
jvm 1 | ssl_debug(2308): Sending certificate handshake message with RSA client certificate…
jvm 1 | ssl_debug(2308): Sending client_key_exchange handshake message (1024 bit)…
jvm 1 | ssl_debug(2308): Sending certificate_verify handshake message…
jvm 1 | ssl_debug(2308): Sending change_cipher_spec message…
jvm 1 | ssl_debug(2308): Sending finished message…
jvm 1 | ssl_debug(2308): Received change_cipher_spec message.
jvm 1 | ssl_debug(2308): Received finished message.
jvm 1 | ssl_debug(2308): Session added to session cache.
jvm 1 | ssl_debug(2308): Handshake completed, statistics:
jvm 1 | ssl_debug(2308): Read 3225 bytes in 6 records, wrote 3337 bytes in 4 records.

and the lines when the server certificate is self-signed:

jvm 1 | ssl_debug(181): Starting handshake (iSaSiLk 3.03)…
jvm 1 | ssl_debug(181): Sending secure renegotiation cipher suite
jvm 1 | ssl_debug(181): Sending v2 client_hello message, requesting version 3.1…
jvm 1 | ssl_debug(181): Received v3 server_hello handshake message.
jvm 1 | ssl_debug(181): Server selected SSL version 3.1.
jvm 1 | ssl_debug(181): Server created new session 57:81:41:21:55:EC:E4:4E…
jvm 1 | ssl_debug(181): CipherSuite selected by server: TLS_RSA_WITH_AES_128_CBC_SHA
jvm 1 | ssl_debug(181): CompressionMethod selected by server: NULL
jvm 1 | ssl_debug(181): Received certificate handshake message with server certificate.
jvm 1 | ssl_debug(181): Server sent a 1024 bit RSA certificate, chain has 1 elements.
jvm 1 | ssl_debug(181): Received certificate_request handshake message.
jvm 1 | ssl_debug(181): Accepted certificate types: RSA, DSS
jvm 1 | ssl_debug(181): Accepted certificate authorities:
jvm 1 | ssl_debug(181): cn=myserver.mycompany.com,ou=BLA,o=BLOU,c=FR
jvm 1 | ssl_debug(181): Received server_hello_done handshake message.
jvm 1 | ssl_debug(181): No client certificate available, sending empty certificate message…
jvm 1 | ssl_debug(181): Sending client_key_exchange handshake message (1024 bit)…
jvm 1 | ssl_debug(181): Sending change_cipher_spec message…
jvm 1 | ssl_debug(181): Sending finished message…
jvm 1 | ssl_debug(181): Received change_cipher_spec message.
jvm 1 | ssl_debug(181): Received finished message.
jvm 1 | ssl_debug(181): Session added to session cache.
jvm 1 | ssl_debug(181): Handshake completed, statistics:
jvm 1 | ssl_debug(181): Read 840 bytes in 6 records, wrote 205 bytes in 3 records.
jvm 1 | ssl_debug(181): Shutting down SSL layer…
jvm 1 | ssl_debug(181): Sending alert: Alert Warning: close notify
jvm 1 | ssl_debug(181): Read 2245 bytes in 1 records, 2211 bytes net, 2211 average.
jvm 1 | ssl_debug(181): Wrote 1162 bytes in 2 records, 1094 bytes net, 547 average.
jvm 1 | ssl_debug(181): Closing transport…

We have tried to change the extended setting (though I have a hard time to understand how this can be related):
watt.security.ssl.client.ignoreEmptyAuthoritiesList=true
but this has not changed anything at all.

Has anyone got a lead on this ?

2

When you are using the self-signed certificate, does the truststore contain the client’s certificate or the certificate of the CA the client’s certificate is issued by? In the first instance, apparently both the server certificate and the client certificate are issued by the same CA, so trust is enabled (they don’t have to be issued by the same CA, but the truststore must contain both of the root CAs certificates if they are not the same CA). In the second instance, it doesn’t sound like the root CA that issues the client’s certificate is in the truststore.

1 Like
3

Is this your self-signed cert: myserver.mycompany.com?
in the log, you have:
jvm 1 | ssl_debug(181): Accepted certificate authorities:
jvm 1 | ssl_debug(181): cn=myserver.mycompany.com,ou=BLA,o=BLOU,c=FR
The server only trust this CA

4

Yes, this is the self-signed certificate returned by the server Mediator is trying to connect to.

What do you mean by “The server only trust this CA” ?

5

When the server I am trying to contact is using the self-signed certificate, the truststores are the following:

  • server truststore (hosting the webservice endpoint): the CA that has signed my client certificate
  • Mediator truststore (client of the call): the self-signed certificate + other CA including the CA that has signed my client certificate

I agree that both the client and server certificates in the first instance are signed by the same CA.

6

We believe cause is identified, actually it looks like the SAP admin is not looking at the proper place to look at the SAP server TrustStore.

Using command line:
openssl s_client -connect myserver.mycompany.com:8443 -showcerts

We noticed:
Acceptable client certificate CA names
/C=FR/O=BLOU/OU=BLA/CN=myserver.mycompany.com

I now understand the remark from Tom Wang since the trace meant exactly the same (a little bit less clear, I had the understanding it was the accepted certificate authorities by the client to validate the server certificate while instead it was the list of acceptable client certificate. OpenSSL output is a little bit more understandable for someone like me :slight_smile: )
jvm 1 | ssl_debug(181): Accepted certificate authorities:
jvm 1 | ssl_debug(181): cn=myserver.mycompany.com,ou=BLA,o=BLOU,c=FR

Hence, the SAP admin should update the SAP TrustStore (another thing to find since he does not seem to know where to do that :slight_smile: ).

However, it makes some explanations on the way WM IS works: if the client certificate signing CA is not in the server acceptable list, then it does not even provide a client certificate to the server. Leading to an “Unauthorized” error.

Somehow, I’d prefer the IS to return the client certificate anyway so the server fails with an understansable error like “client certificate cannot be verified”. It would be a little bit more clear for issue resolution.

Thanks to y’all for helping.