After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

This bug was closed in error by an automated process that we do not control.  Reopening.

(In reply to liuzi from comment #0)
<...snip...>
> rhv-verifypeer=true -oo rhv-cafile=/tmp/ca.pem
> Traceback (most recent call last):
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 381,
> in authenticate
>     self._sso_token = self._get_access_token()
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 617,
> in _get_access_token
>     sso_response = self._get_sso_response(self._sso_url, post_data)
>   File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 694,
> in _get_sso_response
>     curl.perform()
> pycurl.error: (35, 'error:0609E09C:digital envelope
> routines:pkey_set_type:unsupported algorithm')
> 

I'll be honest when saying that I think the treatment of this error looks fine, especially if we consider similar failures on other tools - after all the types/formats of certificates could very well be a factor of the underlying crypto library in use, and I'm not sure we should be trying to parse it, much less give very detailed error messages of why it failed..

In cryptography and authentication, it is pretty common to have an 'all-or-nothing' approach.. So I'll tentatively close this, feel free to reopen.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

This bug is not stale.  It was closed by a process we have no control over.
Please ignore the previous comment.

This is the first time I'm reading through this bug, and even before
reading Klaus's comment 5, I had arrived at the exact same opinion.

OpenSSL -- crypto in general -- error messages are *notoriously* varied,
there are many factors that can go wrong, especially with OS-level
crypto defaults advancing continuously and asynchronously to most
applications.

The error message is:

> pycurl.error: (35, 'error:0609E09C:digital envelope routines:pkey_set_type:unsupported algorithm')

First we have the "compressed" OpenSSL error code, 0609E09C, but then
pycurl actually decodes that for us with ERR_GET_LIB, ERR_GET_FUNC,
ERR_GET_REASON
<https://www.openssl.org/docs/man1.1.1/man3/ERR_GET_LIB.html>:

- library: digital envelope routines
- function: pkey_set_type
- reason: unsupported algorithm

It's entirely possible that the CA.pem file in this case is *valid*,
only the crypto settings on the host where virt-v2v runs (and
consequently, where ovirtsdk4 runs) consider the public key algorithm in
the certificate *too weak*. How is virt-v2v supposed to explain that? It
is an entire OS-level configuration problem, not an application (or even
remote hypervisor) problem.

(

  Just the other day I helped Xueqiang Wei in an offlist thread (msgid
  <1adccb18-f419-4546-48e2-8f68498ef7fc>) resolve an issue
  precisely like this, with regard to UEFI HTTPS Boot. The instructions
  I had provided in
  <https://bugzilla.redhat.com/show_bug.cgi?id=1906500#c27>, for
  creating a CA certificate, no longer worked for Xueqiang Wei. Namely,
  the Certificate Signing Request (CSR) created on a RHEL7 host was now
  impossible to sign on RHEL9:

> Certificate request self-signature did not match the contents
> 80FBFB109E7F0000:error:03000098:digital envelope routines:do_sigver_init:invalid digest:crypto/evp/m_sigver.c:333:
> 80FBFB109E7F0000:error:06880006:asn1 encoding routines:ASN1_item_verify_ctx:EVP lib:crypto/asn1/a_verify.c:201:

  Note the reason code: "invalid digest". That was utterly wrong; there
  was nothing broken with the CSR. Instead, the "genkey" command on the
  RHEL7 machine used such algorithms for the CSR that the RHEL9 host
  considered "weak". After running the command

> update-crypto-policies --set LEGACY

  on the RHEL9 host, the same CSR (from RHEL7) could be signed without
  issues.

)

There's an arms' race between RHEL constantly tightening its crypto
requirements, and virt-v2v having to connect to less-than-bleeding-edge
hypervisors, both on the source side and the destination size. It's a
conflict of interest, and whenever things fall apart because of that,
end-users may encounter the wildest and most misleading error messages,
from deep call stacks in the crypto libs, and we can't do anything about
that in virt-v2v.

Therefore, I'm now going to close this as a duplicate of bug 2062360 now
(even though I'm pretty unconvinced that we should attempt handling this
symptom even under bug 2062360; the real issue is bug 2064740!). Thanks.

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