Can't fetch service configuration form KNIME server in Call Workflow Service

Hi all (including @mpreusse :slight_smile: ),

thanks for all the feedback so far.

Here is an update on where we’re at.
The symptom is that we run into a SSL hostname mismatch issue when executing the Call Workflow Service node, whereas other connections to the KNIME Server (e.g. GET Request node or login via mountpoint) accept the server’s SSL certificate.

Our devs are currently looking into the issue. Still, the underlying problem why the Call Workflow Service node rejects the certificate very likely is an issue with the certificate itself.
Finding out exactly what is wrong may also help our devs to pin down the difference in SSL handling.

We believe the issue may be because the certificate is valid for the company domain, but not all subdomains that may be involved (e.g. if the KNIME Server is running under knime.data.<domain>, but the certificate is only valid for data.<domain>, or similar).
To investigate the certificate, it may suffice to take a look via browser on the WebPortal and see whether the (sub-) domain is part of the Subject or Subject Alternative Name entry.

Another experiment within KNIME would be to use the Explorer Browser node to access files on the server and see whether that runs into any issues (the server should be mounted as https://).

Kind regards
Marvin

Thanks @marvin.kickuth for following up on that issue.

I use a self-signed certificate, I think Knime Server creates one by default. I did no create one on purpose and I did not use/issue/create a certificate. Could that be part of the problem?

Hi @mpreusse,

after investigating this issue more, we found it very likely being caused by the certificates domain name (or common name/ CN) not matching the actual hostname. This issue can occur if there is a subdomain in place, e.g.:
https://mysubdomain.mydomain.com
Here the certificate might only contain the (main) domain name, in this case “mydomain”. To check if this could be the problem, try following the steps @marvin.kickuth described above.

Only if you are sure, that this is not the problem, the self-signing could be relevant:
Your client (in this case the Call Workflow Service node) might not trust your self-signed certificate per default. To resolve this, you would need to export the certificate from your server, then use keytool to store this certificate in a truststore (essentially a file containing the servers you trust).
This truststore path can then be set in the knime.ini file, using:

-Djavax.net.ssl.trustStore=/your/path/cacerts

I hope that this will help you! (and just consider the self-signing being a problem if you checked whether the domain names match :slightly_smiling_face:).

Kind regards,
Leon

2 Likes

Thanks for the update @leon_wenzler!

I tried looking at the certificate with Firefox and Chrome for Mac, I don’t see any details about the domain it was issued for.

Here is the header of the certificate details in Firefox:

The certificate for forum.knime.com says forum.knime.com at Allgemeiner Name.

1 Like