Bug 601222

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,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.