Bug 848049 - Can not connect via SSL/TLS from command line
Can not connect via SSL/TLS from command line
Status: CLOSED NOTABUG
Product: oVirt
Classification: Community
Component: ovirt-engine-cli (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michael Pasternak
Elena
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-14 09:00 EDT by David Jaša
Modified: 2014-01-12 20:45 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-14 12:01:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mpastern: ovirt_requires_release_note?


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-08-14 09:00:12 EDT
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 09:13:35 EDT
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 09:51:46 EDT
$ 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 10:24:40 EDT
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 10:44:47 EDT
(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 11:05:30 EDT
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 12:01:21 EDT
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.

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