Linking error in Broker

(imported topic written by atlauren)


After much trial and failure to configure the broker to use my PEM file, I noticed that the broker log has a variety of errors related to the format of the file. As openssl correctly reads the file, I started to look elsewhere. Since the broker includes its own libssl and libcrypto, I looked at their linked libraries. It turns out that libssl isn’t correctly linked to the libcrypto in the directory:

root@dssiem01 broker]# pwd
[root@dssiem01 broker]# ls -l
total 4152
-rwxr-xr-x 1 root root     312 Apr 11 06:30 IBM_Endpoint_Manager_for_Remote_Control_Broker-9.1.0.swtag
-rwxr-xr-x 1 root root  236309 Apr 11 06:30 jprtool
-rwxr-xr-x 1 root root 2036193 Apr 11 06:30
-rwxr-xr-x 1 root root  376671 Apr 11 06:30
drwxr-xr-x 2 root root    4096 Jun  6 12:14 license
-rwxr-xr-x 1 root root 1588606 Apr 11 06:30 trc_icb
[root@dssiem01 broker]# ldd =>  (0x00f16000) => not found => /lib/ (0x002fb000) => /lib/ (0x00300000)
    /lib/ (0x001d3000)
[root@dssiem01 broker]# ldd =>  (0x00731000) => /lib/ (0x00728000) => /lib/ (0x001f3000)
    /lib/ (0x001d3000)

Thank you,


(imported comment written by Jeremiah_)

Hey Andrew,

The test you are doing is not really correct - ldd will look for the libraries in your LD_LIBRARY_PATH - which will not include either the current directory or the full path to the broker’s install directory (nor should it). The broker loads the openssl libraries at runtime, looking for them in the same directory that it is installed in (ignoring LD_LIBRARY_PATH and system versions of the same library - this is to ensure we always use the version of the openssl library that is shipped with the product).

If you were to run

  • then the libcrypto dependency should resolve correctly - however this again isnt really a true test - as we dont rely on the automatic dependency resolving to load libcrypto - we load it manually first, followed by ssl second (which will use the already-loaded crypto).

One thing to note about the PEM file - certificates/keys within the PEM file should be in the order:

  1. Broker’s certificate
  2. Any intermediate certificates, if required
  3. Root certificate
  4. Broker’s private key

If it is a self-signed certificate, then you will only have 1 and 4 (one CERTIFICATE section and one KEY section). - if its signed by other certificates, the full chain of certificates is needed.

If you can include the log message that is printed (ensure theres no private information included) - then I can have a look at what the cause might be.



(imported comment written by atlauren)

Interesting, thank you.

I’m running the broker on the same box as my TRC Server, so was hoping to use the same CA-signed cert. I guess I’ll look into extracting that private key out of the keystore.


(imported comment written by Jeremiah_)

Yeah, using the same cert should be fine - but do make sure that the broker’s reverse proxy (if you’re using it) does not use the same port as the TRC Server - or one of them will fail to listen.

Also please ensure you’re not making the TRC Server available to the internet - the server is not designed to be accessible outside of an internal network. That’s what the broker’s reverse proxy is designed to handle - it will provide a portal for users on the internet to access and launch the ondemand pages of the server.

Extracting the key from the keystore is a bit of a convoluted task - however there’s a few guides out there on the steps required which use ikeytool and openssl to convert jks -> pkcs12 -> pem.

(imported comment written by atlauren)

Indeed, the server pages will only be accessible internally.

For support of external clients on the Internet, do all of the gateway, tunnel, and broker’s inbound ports need to be open?

They’re all open on my POC, but of course I don’t want that if I can help it.

(imported comment written by Jeremiah_)

Just to note - the reverse proxy is only required if you plan to use the OnDemand Target. If you want to support external clients who will be using an installed target but who want to be able to enter a connection code to establish a session - then you dont need the reverse proxy for that. The reverse proxy is purely to access the ODT launch pages.

External clients only need to be able to access the Broker’s Inbound port (and the Broker reverse proxy port if using ODT). Gateway and tunnels should not be externally accessible as targets connecting to the broker will not use either of those. The browser on the target (if using ODT) will connect to the reverse proxy port, and when the Target itself is launched - it will connect to the broker’s Inbound port to establish the actual session. If using a pre-isntalled target, the first step with the browser is skipped and the target will connect directly to the broker’s Inbound port when a connection code is entered.

(imported comment written by atlauren)

We’re using installed targets, not ODT. If I have this right, the bits should be accessible:

Server – Accessible only to TRC users (IT support staff)

Gateway/Tunnel – Accessible to internal-network systems with installed targets.

Broker – Accessible to external systems

Is that about it?


(imported comment written by Jeremiah_)

Yup, that’s correct - and if you’re not using the ODT at all - then there’s no need for the reverse proxy. So the broker will only need one Inbound listening on a port which is accessible to the external systems (so will probably have to be internet-accessible).

In this case, you dont need a CA-signed certificate for the broker, using a self-signed is also acceptable as the target uses a local trust store (normally pulled down from the server when the target calls home to the server) - which should contain the certificate(s) it needs to access the broker. If the broker certificate is in that file - then there’s no need for the certificate to be signed by a “globally” recognised CA (it does not do any harm to do so - but is not necessary - in your case it would not cost any extra since you will be re-using the server’s certificate).

Having a CA-signed certificate is more important in the case of using the reverse proxy with HTTPS so that clients who access the ODT launch page will receive a properly-validated certificate (since the web browser will use a known/public CA list, rather than a local trust store).

(imported comment written by atlauren)


Thank you, this exchange helped quite a bit.