Bug 885167 - ssl client shall validate server's certificate
ssl client shall validate server's certificate
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: python-qpid (Show other bugs)
Development
Unspecified Unspecified
high Severity high
: 2.3.3
: ---
Assigned To: Ken Giusti
Petr Matousek
:
: 790863 (view as bug list)
Depends On: 965441 1038004
Blocks: 973693
  Show dependency treegraph
 
Reported: 2012-12-07 11:27 EST by Petr Matousek
Modified: 2013-12-04 04:16 EST (History)
6 users (show)

See Also:
Fixed In Version: python-qpid-0.18-5
Doc Type: Bug Fix
Doc Text:
Cause: When the python client is configured to use an SSL connection, a Certificate Authority can be configured to verify the remote's credentials (certificate). A bug in the configuration process allowed the SSL connection to succeed without the CA verification being performed. Consequence: The remote's certificate was never checked. This is a security issue as the remote's authenticity is unknown, yet the secure connection is allowed. Fix: The python client was modified to require that the remote's certificate be validated against the configured CA, and that the certificate contains the correct name of the remote in order for the connection to succeed. Result: The connection will only succeed if the remote is verified and authenticated.
Story Points: ---
Clone Of:
: 973693 (view as bug list)
Environment:
Last Closed: 2013-07-11 09:36:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Matousek 2012-12-07 11:27:33 EST
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
Comment 1 Justin Ross 2013-01-10 10:40:22 EST
Ken, please assess.
Comment 6 Justin Ross 2013-02-27 05:57:18 EST
*** Bug 790863 has been marked as a duplicate of this bug. ***
Comment 8 Ken Giusti 2013-05-01 10:52:27 EDT
Marking POST, as the certificate validation was fixed by patch for this BZ:

https://bugzilla.redhat.com/show_bug.cgi?id=885173
Comment 12 Petr Matousek 2013-05-29 10:29:16 EDT
This issue was tested and seems to work properly.

-> Waiting for doc, please see bug 965441
Comment 15 Petr Matousek 2013-06-17 12:23:45 EDT
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
Comment 17 errata-xmlrpc 2013-07-11 09:36:36 EDT
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

Note You need to log in before you can comment on or make changes to this bug.