If the issue is that on your old client system the cpp client isnt using TLS 1.2 and that is required by your remote Broker-J instance, it seems fairly likely that your local CPP broker wouldn't use it either or in any case would accept what the client is using given they both use the same codebase and NSS, meaning the local test against the entirely different broker doesn't necessarily help all that much.
I'd again suggest updating NSS and its tools to see if that helps. If not, I would try things out on a newer OS (on another system if need be) simply as comparison to verify whether you can get things working there (against the remote Broker-J) with your existing certdb and a more up to date NSS etc. On Fri, 28 Aug 2020 at 19:11, cgh467 <[email protected]> wrote: > > On device localhost, I was using "qpidd --transport ssl --ssl-port 5673 > --ssl-cert-db database --ssl-cert-password-file........." as broker. Then > run my qpid c++ ssl client. It worked. The device has limited memory, could > not install java. The remote is qpid java server. > By the way, I tried to run "qpid-stat -q -b" with remote URL on the device. > it reported ConnectionError too. Even with openssl, I have to give specific > "-tls1_2" option to make a connection to the remote Java server, otherwise, > it does not work either. > I will ask remote java server group to find out their config. > > Thanks so much, > Linda > > > > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
