Description of problem: Assume following case: 1. Clients authentication is not requested by the broker (ssl-require-client-authentication option not provided) 2. python client initiates SSL connection to the SSL broker: After the server's certificate is sent to the client, the certificate shall be validated to identify whether the issuer of the certificated is trusted CA. (the CA that signed the server's certificate is a trusted CA by the client). I am wondering if the server's certificate validation is performed at all. It seems to me that this step is not done, because there is no way how to specify the path to the trusted CA's in the client. How can client do the validation without this knowledge? I am not aware of any "default trusted root file" or something like that, where the client can verify that the certificate issuer is trusted. I would expect behaviour like c++ client: environment variable QPID_SSL_CERT_DB that contains the CA must be passed to the client in order to set-up SSL connection with the server. Otherwise following nss error is shown: "Peer's certificate issuer has been marked as not trusted by the user." Maybe I am missing something, if so, please provide sufficient explanation. Version-Release number of selected component (if applicable): python-qpid-0.18-4 Actual results: no server's certificate check Expected results: server's certificate is validated on client side
Ken, please assess.
*** Bug 790863 has been marked as a duplicate of this bug. ***
Marking POST, as the certificate validation was fixed by patch for this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=885173
This issue was tested and seems to work properly. -> Waiting for doc, please see bug 965441
The connection server's certificate validation against the chain of trust was implemented, although there are some caveats: The validation is done only on RHEL6 and must be demanded by 'ssl_trustfile' connection options. -> VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1023.html