Hide Forgot
According to changelog of qpidc package, I understood that version 0.5.752581-36_cust already contains the change. So I installed latest build, which is qpidd-ssl-0.5.752581-39_cust.el5 on RHEL5 i386 and it did not work. [root@slanina bz533045-2]# ./run Creating certificates... done 2010-jun-08 09:48:21 critical Broker start-up failed: Error in command line options: unknown option ssl-require-client-authentication Use --help to see valid options
ssl-require-client-authentication was not a new option introduced with this change. That error implies/suggests that the ssl module was not loaded. what does /usr/sbinqpidd --help show? Does it list the ssl options?
Verified on RHEL5 i386, qpidd-ssl-0.5.752581-39_cust.el5
Verified also on RHEL5 x86_64, qpidd-ssl-0.5.752581-39_cust.el5
Please reverify with errata build -41 when we get it to candidate
I will verify as soon as qpidc-0.5.752581-41 appears in Brew.
I am having problems with this build (-41) on both RHELs, both archs. Will write more soon.
Created attachment 437162 [details] qpidd.log redhat-release-5Server-5.5.0.2 x86_64 qpidc-perftest-0.5.752581-41.el5 qpidd-0.5.752581-41.el5 qpidd-ssl-0.5.752581-41.el5 qpidc-ssl-0.5.752581-41.el5 1. I create all the certificates using certutil (from nss-tools): echo "hoj11597" > pwdfile.txt echo "aoeunthao eanote haont he432 aontueh" > noise.txt certutil -N -d . -f pwdfile.txt certutil -G -d . -z noise.txt -f pwdfile.txt certutil -S -n ourCA -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d . \ -z noise.txt -f pwdfile.txt certutil -S -n ourServer -s "CN=$HOSTNAME,O=acme,ST=Mass,C=US" \ -c ourCA -t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt certutil -S -n ourClient -s "CN=bob@example.com,O=acme,ST=Mass,C=US" \ -c ourCA -t "u,u,u" -m 1002 -v 120 -d . -z noise.txt -f pwdfile.txt certutil -L -d . -n ourCA -a > cacert.asc 2. I run qpidd using following command: qpidd -d --ssl-require-client-authentication \ --ssl-cert-db $PWD \ --ssl-cert-password-file $PWD/pwdfile.txt \ --ssl-cert-name ourServer \ --auth yes --log-to-file qpidd.log -t 3. I run perftest: export QPID_LOAD_MODULE=`rpm -ql qpidc-ssl | grep sslconnector.so` export QPID_SSL_CERT_NAME=ourClient export QPID_SSL_CERT_DB=$PWD export QPID_SSL_CERT_PASSWORD_FILE=$PWD/pwdfile.txt perftest --count 10 --port 5671 -P ssl -b $HOSTNAME --summary When prompted for password, I press ENTER. 4. Stop the qpidd: qpidd -q (and if I repeat step #3 a couple of times, I get a core dump from perftest) My question is, why is PLAIN password being asked for?
It is vital to add --ssl-sasl-no-dict to qpidd options.
--ssl-sasl-no-dict restricts the valid mechanisms (for ssl connections); if not present the client can select from all those configured for the broker as usual. If the client does not explicitly choose one the choice will be made by the cyrus sasl libs (and is essentially random it seems). So to test EXTERNAL, either choose it explicitly (as for any other mechanism) or force it to be the only one available by specifying --ssl-sasl-no-dict.
Verified on RHEL4 and RHEL5, builds qpidc-0.5.752581-41.el4 qpidc-0.5.752581-41.el5
Both architectures, of course... | RHEL4 | RHEL5 | ------------------------ i386 | OK | OK | x86_64 | OK | OK |
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Desire to utilise the client identity as authenticated by SSL in authorisation. Consequence: Without this feature clients connecting over SSL would need to authenticate themselves by some other username for them to have permission granted via ACLs. Change: Allow the authenticated identity from the underlying SSL connection to be used. This is done by supporting the EXTERNAL mechanism defined for SASL. Result: Can now use the identity as authenticated by SSL (i.e. based on the clients certificate) when writing ACL rules.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0756.html
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,7 +1 @@ -Cause: Desire to utilise the client identity as authenticated by SSL in authorisation. +Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied the access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using the SSL client certificates for authentication.- -Consequence: Without this feature clients connecting over SSL would need to authenticate themselves by some other username for them to have permission granted via ACLs. - -Change: Allow the authenticated identity from the underlying SSL connection to be used. This is done by supporting the EXTERNAL mechanism defined for SASL. - -Result: Can now use the identity as authenticated by SSL (i.e. based on the clients certificate) when writing ACL rules.