Bug 863292 - (vdsm_reg_ca_cert) PRD32 - vdsm-reg: web server CA should be taken from SSL/TLS handshake
PRD32 - vdsm-reg: web server CA should be taken from SSL/TLS handshake
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.2.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.2.0
Assigned To: Alon Bar-Lev
Tareq Alayan
infra
: Improvement
Depends On: 856167
Blocks: 809095 bootstrap-rewrite Simon-RFE-Tracker
  Show dependency treegraph
 
Reported: 2012-10-04 20:53 EDT by Alon Bar-Lev
Modified: 2016-02-10 14:39 EST (History)
12 users (show)

See Also:
Fixed In Version: vdsm-4.10.2-7.0
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alon Bar-Lev 2012-10-04 20:53:04 EDT
CURRENT IMPLEMENTATION

During registration, the CA certificate of the web server is downloaded from ENGINE_URL/ca.crt

PROBLEM IN CURRENT IMPLEMENTATION

There is no way to separate between the CA of the engine that issues certificates for vdsm and the web interface certificate.

JUSTIFICATION

Having 3rd party CA for web server certificate is required to meet organization policy. The 3rd party CA may already be trusted so issuing web server certificate using 3rd party CA makes deployment easier.

NEW IMPLEMENTATION

Acquire CA certificate from the TLS/SSL handshake.
Comment 7 Alon Bar-Lev 2012-10-05 20:14:16 EDT
A draft is available[1]

Side effect, is that registration must be done via HTTPS. It is the desired state, however it will be enforced.

Comments?

[1] http://gerrit.ovirt.org/#/c/8386/
Comment 9 Alon Bar-Lev 2012-10-08 17:51:54 EDT
commit 35005d4fb016b95a0ba3fd71875f099fa612a1a4
Author: Alon Bar-Lev <alonbl@redhat.com>
Date:   Sat Oct 6 02:09:00 2012 +0200

    vdsm-reg: use web server CA extracted from SSL handshake
    
    CURRENT IMPLEMENTATION
    
    During registration, the CA certificate of the web server is downloaded
    from ENGINE_URL/ca.crt
    
    PROBLEM IN CURRENT IMPLEMENTATION
    
    There is no way to separate between the CA of the engine that issues
    certificates for vdsm and the web interface certificate.
    
    JUSTIFICATION
    
    Having 3rd party CA for web server certificate is required to meet
    organization policy. The 3rd party CA may already be trusted so issuing
    web server certificate using 3rd party CA makes deployment easier.
    
    NEW IMPLEMENTATION
    
    Acquire CA certificate from the TLS/SSL handshake.
    
    Change-Id: Iab8727a167de19ac66712309868654ae00c9bf4d
    Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>
    Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=863292
    Reviewed-on: http://gerrit.ovirt.org/8386
    Reviewed-by: Dan Kenigsberg <danken@redhat.com>
Comment 10 Alon Bar-Lev 2012-10-12 18:15:40 EDT
commit f46782207e42ed239a2b13d7a6bd13a9a4947fad
Author: Alon Bar-Lev <alonbl@redhat.com>
Date:   Fri Oct 12 23:32:35 2012 +0200

    vdsm-reg: use M2Crypto instead of pyOpenSSL
    
    M2Crypto is much more supported and has superior coverage.
    
    Change-Id: Id16479e61777dceffaf3c0253ef2b2954e5588a9
    Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>

http://gerrit.ovirt.org/#/c/8522/1

License: One clause BSD
Comment 11 Yaniv Kaul 2012-10-13 10:14:31 EDT
I am sure we dropped m2crypto from vdsm because of issues with it. http://permalink.gmane.org/gmane.comp.emulators.ovirt.vdsm.patches/8145 removed its deep.
Comment 12 Alon Bar-Lev 2012-10-13 10:32:56 EDT
(In reply to comment #11)
> I am sure we dropped m2crypto from vdsm because of issues with it.
> http://permalink.gmane.org/gmane.comp.emulators.ovirt.vdsm.patches/8145
> removed its deep.

Yes, for standard ssl it was right decision. However, python API does not allow fetching the entire chain. Initially I was referred to pyOpenSSL, then found that m2cryto is better maintained... and can be usable for us for other tasks as well, such as CA or simple password encryption within database.

Did not know that it was used before, so now I reintroduce m2crypto for that purpose.
Comment 15 Alon Bar-Lev 2012-12-01 15:45:07 EST
Modified per upstream rebase.
Comment 20 Alon Bar-Lev 2013-03-24 09:31:10 EDT
Test notes:

Environment:

1. vanilla installation of ovirt-engine
2. certification authority to enroll certificates

Preparations:

1. Modify apache ssl.conf to use a certificate and key from 3rd party CA.

2. Restart httpd, and validate that the SSL certificate is of the 3rd party ca.

Test:

1. Install vanilla rhev-h

2. Perform registration using https.

3. Compare the certificate at /etc/pki/vdsm/certs/engine_web_ca.pem to the 3rd party CA certificate. Expectation is that they are the same.

4. After successful deployment, /etc/pki/vdsm/certs/cacert.pem should contain the engine CA certificate. This can be fetched at http://engine/ca.crt
Comment 22 Tareq Alayan 2013-04-08 05:07:21 EDT
Verified. 
Took the CA from different engine deployment as a third party certificate. 
deployed a host.
Comment 23 Itamar Heim 2013-06-11 04:38:14 EDT
3.2 has been released
Comment 24 Itamar Heim 2013-06-11 04:38:14 EDT
3.2 has been released
Comment 25 Itamar Heim 2013-06-11 04:38:15 EDT
3.2 has been released
Comment 26 Itamar Heim 2013-06-11 04:46:15 EDT
3.2 has been released

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