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.
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/
commit 35005d4fb016b95a0ba3fd71875f099fa612a1a4 Author: Alon Bar-Lev <alonbl> 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> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=863292 Reviewed-on: http://gerrit.ovirt.org/8386 Reviewed-by: Dan Kenigsberg <danken>
commit f46782207e42ed239a2b13d7a6bd13a9a4947fad Author: Alon Bar-Lev <alonbl> 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> http://gerrit.ovirt.org/#/c/8522/1 License: One clause BSD
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.
(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.
Modified per upstream rebase.
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
Verified. Took the CA from different engine deployment as a third party certificate. deployed a host.
3.2 has been released