Bug 1626064

Summary: Installing a Websocket Proxy on a el8 Machine fails, because of different public key
Product: [oVirt] ovirt-engine Reporter: Gal Zaidman <gzaidman>
Component: WebSocket ProxyAssignee: Asaf Rachmani <arachman>
WebSocket Proxy sub component: General QA Contact: Lucie Leistnerova <lleistne>
Status: CLOSED DUPLICATE Docs Contact:
Severity: high    
Priority: unspecified CC: arachman, bugs, didi, lleistne
Version: 4.3.0Flags: sbonazzo: ovirt-4.4?
sbonazzo: planning_ack?
sbonazzo: devel_ack+
sbonazzo: testing_ack?
Target Milestone: ovirt-4.4.1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-16 08:16:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1624732    
Bug Blocks: 1460625, 1833770    

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 ***