webMethods

Hi folks,

This is about setting up flow service that consumes a service on the target server over HTTPS and also providing a “client certificate” as the form to identify ourself.
I was able to test this using curl from the same the same box hosting the IS (no -k shortcut employed: the --capath, the --cert, --key and even --proxy were all provided!), and the target server responded as expected.
However things do not work out when using the IS (10.3, no TN available). I’ve followed Debugging TLS or SSL connections in Integration Server, MASSL SSL Connection being dropped and many others and they helped me to overcome sime issues to this last one seems not moving out.

Tasks performed:

• The ‘server’ (target server) certificates were manually extracted and imported into the trust store.
• The ‘client’ key and certificate were imported into the keystore, and its trust path certs as well.
  And both stores were configured in the IS (IS Admin > Security > Keystores).
• Additionally, the ‘client’ key was also set in the “IS Admin > Security > Certificates, SSL Key”
• Finally, the SSL Cache was also cleared (IS Admin > Security > Certificates, Clear SSL Cache).

The testing flow service has, mainly two steps:

• INVOKE pub.security.keystore:setKeyAndChain (set the keystore and the key alias, as shown in the Certificates > SSL Key details)
• INVOKE pub.client:http

However, I’m still getting “Warning: no suitable certificate found - continuing without client authentication” (wrapper.log) which, in some sense, justifies the this post title.

Wading through the wrapper.log (with the SSL debug logfs turned on) there is a hint:

 1.  INFO   | jvm 6    | 2020/09/28 16:07:42 | *** CertificateRequest
2.  INFO   | jvm 6    | 2020/09/28 16:07:42 | Cert Types: RSA, DSS, ECDSA
3.  INFO   | jvm 6    | 2020/09/28 16:07:42 | Supported Signature Algorithms: SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA384withRSA, Unknown (hash:0x5,
4.  INFO   | jvm 6    | 2020/09/28 16:07:42 | Cert Authorities:
5.  INFO   | jvm 6    | 2020/09/28 16:07:42 | <Empty>
6.  INFO   | jvm 6    | 2020/09/28 16:07:42 | HTTP Handler 192.168.80.81, READ: TLSv1.2 Handshake, length = 4
7.  INFO   | jvm 6    | 2020/09/28 16:07:42 | *** ServerHelloDone
8.  INFO   | jvm 6    | 2020/09/28 16:07:42 | Warning: no suitable certificate found - continuing without client authentication
9.  INFO   | jvm 6    | 2020/09/28 16:07:42 | *** Certificate chain
10.  INFO   | jvm 6    | 2020/09/28 16:07:42 | <Empty>
11.  INFO   | jvm 6    | 2020/09/28 16:07:42 | ***
12.  INFO   | jvm 6    | 2020/09/28 16:07:42 | *** ClientKeyExchange, DH

Line 8: still getting ‘no suitable certificate found’. (But how come not being able to find the certificate? The certificate is in the keystore.)

What I’m missing?

Feng,

Server had sent empty certificate authorities list during SSL handshake

4. INFO | jvm 6 | 2020/09/28 16:07:42 | Cert Authorities:
5. INFO | jvm 6 | 2020/09/28 16:07:42 | <Empty

IS (as a client) wouldn’t send its CA unless watt.security.ssl.client.ignoreEmptyAuthoritiesList property is set to ‘true’

watt.security.ssl.client.ignoreEmptyAuthoritiesList:

Specifies whether an Integration Server client will send its CA certificate when it receives an empty list of trusted authorities from the SSL server. If set to true, the Integration Server client accepts empty trusted authorities lists from the SSL server and returns its CA certificate.

-Senthil

Wow!
Senthilkumar_G, this…

… made all the diference. Hurray! It worked!
I’was pulling my hair for many days in a row, and you made my day!

Additionally:

I removed it, cleared the SSL Cache, and ran the test service. Result: found no difference at all.

Hence, to summarize all: the final solution is:

… and …

… and…

Thank a lo Feng & Senthilkumar!

After wasting lot’s of days I stumbled upon this piece and must say

watt.security.ssl.client.ignoreEmptyAuthoritiesList property is set to ‘ true ’

is the KEY!

Regards,
Sanket