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
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.
*** Bug 1835642 has been marked as a duplicate of this bug. ***
Encountered the same issue on CentOS8
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 ***