Description of problem: The JMS client will succeed in connecting to a broker whose certificate has a random string as the common name. It should (at least as an option) verify that the CN matches the hostname it believes it has connected to. Version-Release number of selected component (if applicable): 1.2 How reproducible: 100% Steps to Reproduce: 1. start qpidd with SSL enabled using certificate where CN=non.existent.server.com 2. connect over SSL from JMS client Actual results: Connects without error. Expected results: An error should be raised. Additional info:
This is tracked in upstream via https://issues.apache.org/jira/browse/QPID-2444 This is fixed by rev 925469 in Qpid trunk. SSLTest in the systests has a test case for this. In order to enable hostname verification, you need to use ssl_verify_hostname='true' in the broker URL. Ex "amqp://guest:guest@test/?brokerlist='tcp://<hostname>:5671?ssl='true'&ssl_verify_hostname='true''"
fixed in qpid-java-client-0.7.946106-10.el5 mentioned test passes validated on RHEL5.5/RHEL 4.8 i386 / x86_64 packages: # rpm -qa | grep -E '(qpid|openais|rhm)' | sort -u openais-0.80.6-16.el5_5.7 openais-devel-0.80.6-16.el5_5.7 python-qpid-0.7.946106-14.el5 qpid-cpp-client-0.7.946106-17.el5 qpid-cpp-client-devel-0.7.946106-17.el5 qpid-cpp-client-devel-docs-0.7.946106-17.el5 qpid-cpp-client-ssl-0.7.946106-17.el5 qpid-cpp-mrg-debuginfo-0.7.946106-14.el5 qpid-cpp-server-0.7.946106-17.el5 qpid-cpp-server-cluster-0.7.946106-17.el5 qpid-cpp-server-devel-0.7.946106-17.el5 qpid-cpp-server-ssl-0.7.946106-17.el5 qpid-cpp-server-store-0.7.946106-17.el5 qpid-cpp-server-xml-0.7.946106-17.el5 qpid-java-client-0.7.946106-10.el5 qpid-java-common-0.7.946106-10.el5 qpid-tools-0.7.946106-11.el5 rhm-docs-0.7.946106-5.el5 rh-tests-distribution-MRG-Messaging-qpid_common-1.6-53 ->VERIFIED
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: Previously, the JMS client succeeded in connecting to a broker whose certificate had a random string as its common name. With this update, an option (ssl_verify_hostname=['true'/'false']) is introduced that verifies that the CN matches the hostname it believes it has connected to, if it does not, an error is raised.
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-0773.html