Bug 885167

Summary:	ssl client shall validate server's certificate
Product:	Red Hat Enterprise MRG	Reporter:	Petr Matousek <pematous>
Component:	python-qpid	Assignee:	Ken Giusti <kgiusti>
Status:	CLOSED ERRATA	QA Contact:	Petr Matousek <pematous>
Severity:	high	Docs Contact:
Priority:	high
Version:	Development	CC:	jross, jwulf, kgiusti, lzhaldyb, mcressma, tmckay
Target Milestone:	2.3.3
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:
Clones:	973693 (view as bug list)		Environment:
Last Closed:	2013-07-11 13:36:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	965441, 1038004
Bug Blocks:	973693

Description Petr Matousek 2012-12-07 16:27:33 UTC

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 15:40:22 UTC

Ken, please assess.

Comment 6 Justin Ross 2013-02-27 10:57:18 UTC

*** Bug 790863 has been marked as a duplicate of this bug. ***

Comment 8 Ken Giusti 2013-05-01 14:52:27 UTC

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 14:29:16 UTC

This issue was tested and seems to work properly.

-> Waiting for doc, please see bug 965441

Comment 15 Petr Matousek 2013-06-17 16:23:45 UTC

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 13:36:36 UTC

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