Bug 1626064 - Installing a Websocket Proxy on a el8 Machine fails, because of different public key
Summary: Installing a Websocket Proxy on a el8 Machine fails, because of different pub...
Keywords:
Status: CLOSED DUPLICATE of bug 1624732
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: WebSocket Proxy
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.4.1
: ---
Assignee: Asaf Rachmani
QA Contact: Lucie Leistnerova
URL:
Whiteboard:
: 1835642 (view as bug list)
Depends On: 1624732
Blocks: oVirt_on_Fedora 1833770
TreeView+ depends on / blocked
 
Reported: 2018-09-06 13:44 UTC by Gal Zaidman
Modified: 2020-06-16 08:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-16 08:16:58 UTC
oVirt Team: Integration
Embargoed:
sbonazzo: ovirt-4.4?
sbonazzo: planning_ack?
sbonazzo: devel_ack+
sbonazzo: testing_ack?


Attachments (Terms of Use)

Description Gal Zaidman 2018-09-06 13:44:54 UTC
Description of problem:
The problem occurs when we try to install a websocket proxy on a fc28 machine, with any engine machine.
when trying to debug the issue I saw different behaver in fc28 and centos
fc28 runs with m2crypto 0.28 and openssl 1.1
centos run with m2crypto 0.21 and openssl 1.0

the relevant functions are in remote_rngine.py:
_genCsr
enroll_cert
_enroll_cert_auto_ssh

the process is:
1. fc28 machine creates an RSA private key
2. create an x509 request and set the public key
3. sign the cert with sha1
4. saves the public key got from calling cert.get_pubkey().as_pem(cipher=None)

here is when we see the different behavior,
in centos:
cert.get_pubkey().as_pem(cipher=None) returns a public key of 460 char which is the same as the public key returned when executing the following command on the cert\request file:
cert:
openssl x509 -in$(path_to_cert_file) -noout -pubkey
request:
openssl req -in$(path_to_req_file) -noout -pubkey
but different from the public key created by EVP.PKey() at the beginning of _genCsr

in Fedora:
ert.get_pubkey().as_pem(cipher=None) returns a public key of 1700 chars which is the same as the public key created by EVP.PKey() at the beginning of _genCsr
but different from the one we get when running the above openssl commands.

5. the process continues until entering _enroll_cert_auto_ssh, where we send the request to the engine machine and create the cert with pki-enroll-request.sh, read the cert content from the engine, and compare the public key of the cert (which is the shorter 460 chars key) to our pubkey returned from cert.get_pubkey().as_pem(cipher=None) (which is the longer 1700 chars key)

Notes:
1. pki-enroll-request.sh, will fail because of:
https://bugzilla.redhat.com/show_bug.cgi?id=1624732
a workaround would be to edit pki-enroll-request.sh and instead of subject=$2 enter subject=$(openssl x509 -in ../ca.pem -noout -text| \
                grep '^[ ]*Subject'|head -1|tr -d [[:space:]]|tr , /| \
                sed 's/Subject:/\//g')
which reads the subject from ca.pem
2. there are alot of changes in the m2crypto and openssl versions, can be found here:
https://www.openssl.org/news/changelog.html#x10
https://gitlab.com/m2crypto/m2crypto/blob/master/CHANGES

Comment 1 Sandro Bonazzola 2019-01-21 08:28:50 UTC
re-targeting to 4.3.1 since this BZ has not been proposed as blocker for 4.3.0.
If you think this bug should block 4.3.0 please re-target and set blocker flag.

Comment 2 Asaf Rachmani 2020-05-14 09:10:30 UTC
*** Bug 1835642 has been marked as a duplicate of this bug. ***

Comment 3 Asaf Rachmani 2020-05-14 09:20:33 UTC
Encountered the same issue on CentOS8

Comment 5 Yedidyah Bar David 2020-06-16 08:16:58 UTC
Closing as duplicate of bug 1624732. In theory, they mention two specific issues. In practice, it's impossible to verify one of them without the other. Both because they are about the same flow, in very "close" points of it (although in somewhat different parts of the code), and also because when working on 1624732 I didn't try very cleanly to split the patches between them.

*** This bug has been marked as a duplicate of bug 1624732 ***


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