Bug 848049

Summary:	Can not connect via SSL/TLS from command line
Product:	[Retired] oVirt	Reporter:	David Jaša <djasa>
Component:	ovirt-engine-cli	Assignee:	Michael Pasternak <mpastern>
Status:	CLOSED NOTABUG	QA Contact:	Elena <edolinin>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, bazulay, dyasny, iheim, srevivo, ykaul
Target Milestone:	---	Flags:	mpastern: ovirt_requires_release_note?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-14 16:01:21 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:

Description David Jaša 2012-08-14 13:00:12 UTC

Description of problem:
Can not connect via SSL/TLS from command line

Version-Release number of selected component (if applicable):
ovirt-engine-cli-3.1.0.7-1.el6.noarch
ovirt-engine-sdk-3.1.0.5-1.el6.noarch
(el6 rebuild of packages for fc17 from ovirt.org0

How reproducible:
always

Steps to Reproduce:
1. ovirt-shell -l https://${OVIRT}/api -u ${USER} -p ${PASS} -C ${CERT} -c
2.
3.
  
Actual results:
error: [ERROR]::oVirt API connection failure,
[Errno 336265218] _ssl.c:339: error:140B0002:SSL routines:SSL_CTX_use_PrivateKey_file:system lib
... 
[oVirt shell (disconnected)]#


Expected results:
ovirt-shell connects as USER, PASS and CERT are all valid:
$ curl -I --cacert ${CA_FILE} -u ${USER}:${PASS} -H "Content-Type: application/xml" "https://${OVIRT}/api" 
HTTP/1.1 200 OK
Date: Tue, 14 Aug 2012 12:57:05 GMT
Set-Cookie: JSESSIONID=3Im0jbuvr50+s+Z80Zpixts9; Path=/api; Secure
Link: <${OVIRT}/api/capabilities>, ...
Connection: close
Content-Type: text/plain; charset=UTF-8

* wouldn't get 200 OK with curl if any of the USER, PASS or CERT (CA cert)
  variables was incorrect
* CA isn't available in any system/user-wide store, only in the file ${CERT}

Additional info:

Comment 1 Michael Pasternak 2012-08-14 13:13:35 UTC

it's sounds like a permission issue on the cert. file for the ovirt-shell,
can you verify that?

Comment 2 David Jaša 2012-08-14 13:51:46 UTC

$ ls -ldZ ${CA_FILE}
-rw-r--r--. djasa users unconfined_u:object_r:user_home_t:s0 ${CA_FILE}

running ovirt-shell as djasa in shell - can not connect
running curl as djasa in the very same shell - can connect

--> doesn't sound like permission issue

Comment 3 Michael Pasternak 2012-08-14 14:24:40 UTC

this is cert processing/handshake failure in https lib, 

- please see how to create/deploy SSL env. for the engine [1]
- check if you see anything related to SSL in server.log

[1] http://wiki.ovirt.org/wiki/Building_Engine_Draft#Enable_SSL_port_8443_in_the_application_server_.28optional.29

Comment 4 David Jaša 2012-08-14 14:44:47 UTC

(In reply to comment #3)
> this is cert processing/handshake failure in https lib, 
> 
> - please see how to create/deploy SSL env. for the engine [1]

It is deployed correctly - everything else works just fine (firefox, curl, wget)

> - check if you see anything related to SSL in server.log

/var/log/ovirt-engine/server.log is silent
/var/log/httpd/ssl_request_log contains entry like this for curl access:
[14/Aug/2012:16:35:07 +0200] ${CLIENT_IP} TLSv1 DHE-RSA-AES256-SHA "HEAD /api HTTP/1.1" -

/var/log/httpd/ssl_*_log remains silent when I run o-s, but a pcap shows few packets.

Comment 7 Michael Pasternak 2012-08-14 15:05:30 UTC

ok, got it, cert_file should be PEM formatted file, see [1], key_file is the name of a PEM formatted file that contains your private key.

[1] http://docs.python.org/library/httplib.html

Comment 8 David Jaša 2012-08-14 16:01:21 UTC

cert_file is engine's ca.pem.

And after further investigation, I found that cert_file _is not_ CA trust store to verify server cert against, it is actually a client certificate file used for establishing client identity on the server.

$ ovirt-shell -l https://${OVIRT}/ -u ${USER} -p ${PASS} -c

connects fine (a basic scenario I didn't even try) so the only bug here is bug 848046.