On Sat, Jul 25, 2020 at 5:24 AM Lynn Dixon <ldi...@redhat.com> wrote:

> All,
> I recently bought a wildcard certificate for my lab domain (shadowman.dev)
> and I replaced all the certs on my RHV4.3 machine per our documentation.
> The WebUI presents the certs successfully and without any issues, and
> everything seemed to be fine, until I tried to upload a disk image (or an
> ISO) to my storage domain.  I get this error in the events tab:
> https://share.getcloudapp.com/p9uPvegx
> [image: image.png]
> I also see that the disk is showing up in my storage domain, but its
> showing "Paused by System" and I can't do anything with it.  I cant even
> delete it!
> I have tried following this document to fix the issue, but it didn't work:
> https://access.redhat.com/solutions/4148361
> I am seeing this error pop into my engine.log:
> https://pastebin.com/kDLSEq1A
> And I see this error in my image-proxy.log:
> WARNING 2020-07-24 15:26:34,802 web:137:web:(log_error) ERROR
> [] PUT /tickets/ [403] Error verifying signed ticket: Invalid
> ovirt ticket (data='------my_ticket_data-----', reason=Untrusted
> certificate) [request=0.002946/1]

This means ssl_* configuration in broken.

We have 2 groups:

Client ssl configuration:

# Key file for SSL connections
ssl_key_file = /etc/pki/ovirt-engine/keys/image-proxy.key.nopass

# Certificate file for SSL connections
ssl_cert_file = /etc/pki/ovirt-engine/certs/image-proxy.cer

And engine SSL configuration:

# Certificate file used when decoding signed token
engine_cert_file = /etc/pki/ovirt-engine/certs/engine.cer

# CA certificate file used to verify signed token
engine_ca_cert_file = /etc/pki/ovirt-engine/ca.pem

engine configuration is used to verify signed ticket used by engine when
adding tickets to the proxy. This is internal flow that clients should not
about. You should not replace these unless you are using also custom
for engine itself - very unlikely and maybe unsupported.
(Didi please correct me on this).

SSL client configuration is used when communicating with clients, and does
not depend on engine ssl configuration. You can replace these with your

Can you share your /etc/ovirt-imageio/ovirt-imageio-proxy.conf?

The main issue with the current configuration is that we don't have
ssl_ca_cert configuration,
assuming that ssl_cert_file is a self signed certificate that includes the
CA certificate, since
this is what engine is creating.

In 4.4, we have more flexible configuration that should work for your case:

$ cat /etc/ovirt-imageio/conf.d/50-engine.conf
enable = true
key_file = /etc/pki/ovirt-engine/keys/apache.key.nopass
cert_file = /etc/pki/ovirt-engine/certs/apache.cer
ca_file = /etc/pki/ovirt-engine/apache-ca.pem

Adding ssl_ca_cert to imageio 1.5.3 looks simple enough, so I posted this
completely untested patch:

You can try to upgrade your proxy to using this build:

Add a yum repo file with this baseurl=.

Again this is untested, but you seem to be in the best place to test it,
since I don't have any real certificates for testing.

It would also be useful if you file a bug for this issue.


Now, when I bought my wildcard, I was given a root certificate for the CA,
> as well as a separate intermediate CA certificate from the provider.
> Likewise, they gave me a certificate and a private key of course. The root
> and intermediate CA's certificates have been added
> to /etc/pki/ca-trust/source/anchors/ and I did an update-ca-trust.
> I also started experiencing issues with the ovpn network provider at the
> same time I replaced the SSL certs, but I disregarded it at the time, but
> now I am thinking its related.  Any advice on what to look for to fix the
> ovirt-imageio-proxy?
> Thanks!
> *Lynn Dixon* | Red Hat Certified Architect #100-006-188
> *Solutions Architect* | NA Commercial
> Google Voice: 423-618-1414
> Cell/Text: 423-774-3188
> Click here to view my Certification Portfolio <http://red.ht/1XMX2Mi>
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
List Archives: 

Reply via email to