Description of problem: oVirt python SDK ignores the system defined CA certs. It's possible to pass a CA cert file with ca_file parameter in the API construction but also in that case python SDK will try to use just that cert ignoring the system defined CA certs. The default behavior of ssl python implementation since 2.7.9 (but also backported to 2.7.5 in RHEL) is now to load the default CA certs just with ssl.create_default_context() https://docs.python.org/3/library/ssl.html#ssl.create_default_context and this difference can lead to sneaky behaviors. Adding a flag to optionally load the system defined CA certs can solve it.
How does ssl.create_default_context() determine the location of the system define CA certs?
Unfortunately the documents reports just: Load a set of default “certification authority” (CA) certificates from a filesystem path defined when building the OpenSSL library. https://docs.python.org/3/library/ssl.html#ssl.set_default_verify_paths Probably the easiest, but ugly, way to get the same CA cert list is just: ctx = ssl.create_default_context() cacertlist = ctx.get_ca_certs() and consume cacertlist (Note: Certificates in a capath directory aren’t loaded unless they have been used at least once.) Otherwise we should look at the code and try doing the same.
That method returns a list of Python objects (or arrays of bytes), that would then need to be serialized and saved to a temporary file, together with the file specified by the user, as pycurl only supports one file. It may be better to add to the SDK support for multiple files, so that the "ca_pem" parameter accepts a string, like it does today, or a list of strings: ca_path=['this.pem', 'that.pem', ...] If that is added then you can just pass the system wide CA bundle explicitly: ca_path=['this.pem', 'that.pem', '/etc/pki/tls/certs/ca-bundle.crt'] Would that work for hosted engine-setup? Do we need this in 3.6 or will the patch that you submitted for hosted engine be enough to solve the issue? If that patch is enough, then I prefer to target this for version 4 of the SDK.
Patch https://gerrit.ovirt.org/#/c/56051/ will simply made hosted-engine-setup avoid trusting system wide CA so, if the apache cert got replaced by an externally signed cert, hosted-engine-setup will notice it and ask the user to provide the correct CA file or proceed in insecure mode. So it will solve the issue for 3.6 but it's not that nice on user perspective since it will ignore also there the system configured CAs. On user perspective I think it would be much better to trust the system trusted CAs but I think we could wait 4.0 for this.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
seems to work fine: cd /etc/pki/ca-trust/source/ ln -s /etc/pki/ovirt-engine/certs/ca.der ./ca.crt update-ca-trust ipython from ovirtsdk4 import Connection con = Connection(url='https://mo-3.rhev.lab.eng.brq.redhat.com/ovirt-engine/api', username='admin@internal', password='123456') api = con.system_service() dc = api.data_centers_service() dc.list() returned list of DCs, which means it connected