Hi Everyone,
I’ve spent over a week configuring and troubleshooting our new install of Tivoli Remote Control broker but still can’t connect to a target computer using the Broker server. I could really use some help, I don’t have any experience with Tivoli Remote Control Server. Sessions to a target computer internally using the Tivoli Remote Control Server directly work fine. That’s great for LAN connected computers but not for connecting to computers over the internet.
The controller software starts up on my local computer (via a Tivoli Remote Connection server call) and attempts to connect to the Broker on port 443 - this lasts for about 30-40 seconds. I don’t receive a code request dialog box I just get ‘unable to connect to broker’. I think it’s a port 443 problem. I run netstat, curl, telnet but no port 443 is open or listening on the Broker server.
I’m assuming that when you configure the Broker role, the port config is taken care of. I must be missing something, this doesnt seem right.
When the controller app starts on my workstation it looks for https://brokerserverfqdn:443 (as configured on the TRC server) and fails.
We’re using a self signed certificate created using ikeyman and this p12 file has been transferred to the Broker. The certificate generation steps completed without error and importing it into TRC was error free. I’ve placed the *.p12 key store into the /var/opt/ibm/trc/broker directory. When I restart the ibmtrcicb service after placing it in this directory two *.crt files are automatically generated. I’m guessing this is normal. The trusted key in the Broker.certs file is the same as the key that I configured to register the broker in the Tivoli Remote Control Server.
Here’s a quick output of the last lines of the TRCBROKER log file. It doesn’t suggest any certificate issues.
015.11.23-06:26:37.728 (GMT) DEBUG [4148942528] 0x96629f8: tls context refcount decreased 0
2015.11.23-06:26:37.728 (GMT) DEBUG [4148942528] 0x96629f8: releasing tls context
2015.11.23-06:26:37.728 (GMT) INFO [4148942528] comm: checking broker.certs trust store
2015.11.23-06:26:37.729 (GMT) DEBUG [4148942528] trust_mgr: attempting to use algorithm: ‘sha256’ to verify trust store
2015.11.23-06:26:37.729 (GMT) INFO [4148942528] comm: next heartbeat in 86400 seconds
2015.11.23-06:26:37.729 (GMT) INFO [4148942528] Waking up recording thread
2015.11.23-06:26:37.729 (GMT) INFO [4148942528] Waking up recording thread
2015.11.23-06:26:37.729 (GMT) DEBUG [4148942528] inbound: creating 1 inbound connections
2015.11.23-06:26:37.729 (GMT) DEBUG [4148942528] threadpool: starting worker 1, job 0x9664b30
2015.11.23-06:26:37.729 (GMT) INFO [4142684992] Recording thread awake
2015.11.23-06:26:37.729 (GMT) INFO [4142684992] Recording thread asleep
2015.11.23-06:26:37.729 (GMT) INFO [4132436800] Recording thread awake
2015.11.23-06:26:37.729 (GMT) INFO [4132436800] Recording queue is empty
2015.11.23-06:26:37.729 (GMT) INFO [4132436800] Recording thread asleep
2015.11.23-06:26:37.729 (GMT) DEBUG [4113558336] threadpool: worker 1 starting
2015.11.23-06:26:37.729 (GMT) DEBUG [4113558336] threadpool: worker 1 running job 0x9664b30
2015.11.23-06:26:37.729 (GMT) DEBUG [4113558336] inbound: I0000 thread started for inbound connection
2015.11.23-06:26:37.730 (GMT) DEBUG [4113558336] 0xf5b00478: tls context refcount increased to 1
2015.11.23-06:26:37.733 (GMT) DEBUG [4113558336] openssl_setup_context: PEM password specified
2015.11.23-06:26:37.733 (GMT) INFO [4113558336] openssl: loading PKCS#12 certificate from bne-bfix-01.p12
2015.11.23-06:26:37.736 (GMT) INFO [4113558336] openssl: PKCS#12 did not contain certificate chain
2015.11.23-06:26:37.737 (GMT) INFO [4113558336] Certificate uses Key Algorithm: ‘RSA’ of size: 2048 bits - and signature algorithm: 'sha256WithRSAEncryption’
2015.11.23-06:26:37.737 (GMT) INFO [4113558336] I0000 listening on :::443
2015.11.23-06:26:37.738 (GMT) DEBUG [4148942528] threadpool: created new worker for job 0x9664b30, workers waiting 0
2015.11.23-06:26:37.738 (GMT) DEBUG [4148942528] inbound: creating 0 broker connections
2015.11.23-06:26:37.738 (GMT) DEBUG [4148942528] comm: checking heartbeat (trigger = 0)
2015.11.23-06:26:37.738 (GMT) DEBUG [4148942528] comm: next heartbeat check in 86400 seconds (trigger = 0)
Here’s the crucial bit of my broker config file;
Public address and port for this broker
PublicBrokerURL = https://Brokerserver.fqdn:443
Server configuration
ServerURL = https://TivoliRemoteControlServer.fqdn/trc/
Proxy configuration
ProxyURL = : for standard HTTP proxy server
ProxyURL = trcgw://: for TRC Gateway
ProxyURL =
Defaults for connections
DefaultPortToListen = 443
DefaultSourcePort = 0
DefaultBindTo = 0.0.0.0
DefaultBindTo6 = ::
DefaultRetryDelay = 45
DefaultKeepAlive = 900
DefaultTLSCertificateFile = ThisIsTheSelfSignedCertificate.p12
DefaultTLSCertificatePassphrase = ThisIsThePassPhrase
DefaultTLSCipherList = ALL+AES+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!MD5:!RC4:@STRENGTH
Defaults for HTTP and HTTPS connections
DefaultHTTPHeaderLineLimit = 8190
DefaultHTTPHeaderLimit = 16384
Some other bits and pieces to provide background;
There’s no multi site/multi branch/multi DMZ topologies.
This is internet computer, to broker (in the DMZ), to Remote Control Server, to Controller
This single Broker is in a DMZ. There are firewall rules in place that allow bigfix comms and port 443 comms between this Broker and the Tivoli Remote Control Server.
This same Broker server currently acts as the DMZ based internet relay for internet based computers. This role works just fine. I can push fixlets and tasks over the internet.
I’m not using a gateway. Is a gateway a mandatory requirement?
Do I have to have a gateway?
I’m not using a proxy. I’m pretty sure I don’t have to be using one for this type of configuration?
The Broker OS is CentOS ibmtrcicb service is running and restarts on command just fine
I’d really appreciate some assistance. It’s probably something really obvious but I’m not seeing it.