Bug 2186439

Support tells me this is due to virt viewer being unable to use the CA from the console.vv file ( https://bugzilla.redhat.com/show_bug.cgi?id=1751073#c3 )

I tried importing the ovirt-engine CA into my users "Trusted Root Certification Authorities" store. But that does not change anything. Where on disk does virt-viewer with VNC expect the CA to be stored on Windows?

(In reply to Klaas Demter from comment #1)
> Support tells me this is due to virt viewer being unable to use the CA from
> the console.vv file ( https://bugzilla.redhat.com/show_bug.cgi?id=1751073#c3
> )
> 
> I tried importing the ovirt-engine CA into my users "Trusted Root
> Certification Authorities" store. But that does not change anything. Where
> on disk does virt-viewer with VNC expect the CA to be stored on Windows?

AFAICT that's the right thing to do. Should be the place it's complaining about above - /etc/pki/tls/certs/. Maybe poke support again about that

The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

(In reply to Michal Skrivanek from comment #2)
> (In reply to Klaas Demter from comment #1)
> > Support tells me this is due to virt viewer being unable to use the CA from
> > the console.vv file ( https://bugzilla.redhat.com/show_bug.cgi?id=1751073#c3
> > )
> > 
> > I tried importing the ovirt-engine CA into my users "Trusted Root
> > Certification Authorities" store. But that does not change anything. Where
> > on disk does virt-viewer with VNC expect the CA to be stored on Windows?
> 
> AFAICT that's the right thing to do. Should be the place it's complaining
> about above - /etc/pki/tls/certs/. Maybe poke support again about that

It's windows, "/etc/pki/tls/certs/" does not exist there, path would be something like C:\etc\pki\tls\certs or maybe relative to the binary, I am unsure how that windows port works :) Hence the question, at which path does it expect the ca file :)

I think encrypted VNC connection does not currently work with the remote-viewer.exe VNC client for Windows.

Bug 1597085#c20 suggests to use tigerVNC.
Can you try using tigerVNC ?

(In reply to Klaas Demter from comment #4)
> (In reply to Michal Skrivanek from comment #2)
> > (In reply to Klaas Demter from comment #1)
> > > Support tells me this is due to virt viewer being unable to use the CA from
> > > the console.vv file ( https://bugzilla.redhat.com/show_bug.cgi?id=1751073#c3
> > > )
> > > 
> > > I tried importing the ovirt-engine CA into my users "Trusted Root
> > > Certification Authorities" store. But that does not change anything. Where
> > > on disk does virt-viewer with VNC expect the CA to be stored on Windows?
> > 
> > AFAICT that's the right thing to do. Should be the place it's complaining
> > about above - /etc/pki/tls/certs/. Maybe poke support again about that
> 
> It's windows, "/etc/pki/tls/certs/" does not exist there, path would be
> something like C:\etc\pki\tls\certs or maybe relative to the binary, I am
> unsure how that windows port works :) Hence the question, at which path does
> it expect the ca file :)

GTK-VNC would likely be looking at:

  C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\CA\cacert.pem 

(you can confirm by passing --gtk-vnc-debug to remote-viewer.exe - the log will show the directories it looks at)

Hi,
thanks for the pointers, I managed to figure out the paths it searches for on windows:

/etc/pki/tls/certs/ca-bundle.crt corresponds to "C:\etc\pki\tls\certs\ca-bundle.crt"
/usr/x86_64-w64-mingw32/sys-root/mingw/etc/pki/CA/cacert.pem to "C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\CA\cacert.pem"

I've placed the ovirt ca at both paths, but it's still failing, so I would guess Uri is correct :) Sadly I can't use tigerVNC, but noVNC and ssh serial console is good enough for now.

Is this something that will/should be fixed on the Red Hat side? Or is this out of scope because RHV is sunset?

Greetings
Klaas


Additional info -- debug output with the ca in place at the two paths that it complained about before:
C:\Program Files\VirtViewer v9.0-96\bin>remote-viewer.exe -vvv --gtk-vnc-debug "c:\Users\username\Downloads\console.vv"

C:\Program Files\VirtViewer v9.0-96\bin>Guest (NULL) has a vnc display
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:46.459: ../../src/vncconnection.c Init VncConnection=000000000595D940
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:46.460: ../../src/vncdisplaykeymap.c Using Win32 virtual keycode mapping
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:46.461: ../../src/vncdisplay.c Grab sequence is now Control_L+Alt_L
Opening connection to display at c:\Users\demtekaa\Downloads\console.vv
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:46.482: ../../src/vncconnection.c Open host=hostname.tld port=5900
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.079: ../../src/vncconnection.c Open coroutine starting
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.080: ../../src/vncconnection.c Started background coroutine
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.082: ../../src/vncconnection.c Resolving host hostname.tld 5900
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.089: ../../src/vncconnection.c Trying one socket
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.090: ../../src/vncconnection.c Socket pending
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.125: ../../src/vncconnection.c Finally connected
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.150: ../../src/vncconnection.c Emit main context 13
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.151: ../../src/vncdisplay.c Grab sequence is now
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.155: ../../src/vncdisplay.c Connected to VNC server
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.155: ../../src/vncconnection.c Protocol initialization
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.157: ../../src/vncconnection.c Read error A non-blocking socket operation could not be completed immediately.
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.158: ../../src/vncconnection.c Server version: 3.8
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.159: ../../src/vncconnection.c Sending full greeting
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.160: ../../src/vncconnection.c Using version: 3.8
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.235: ../../src/vncconnection.c Possible auth 19
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.280: ../../src/vncconnection.c Emit main context 11
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.281: ../../src/vncconnection.c Thinking about auth type 19
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.347: ../../src/vncconnection.c Decided on auth type 19
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.387: ../../src/vncconnection.c Waiting for auth type
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.444: ../../src/vncconnection.c Choose auth 19
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.489: ../../src/vncconnection.c Checking if credentials are needed
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.508: ../../src/vncconnection.c No credentials required
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.555: ../../src/vncconnection.c Read error A non-blocking socket operation could not be completed immediately.
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.596: ../../src/vncconnection.c Read error A non-blocking socket operation could not be completed immediately.
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.618: ../../src/vncconnection.c Possible VeNCrypt sub-auth 261
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.619: ../../src/vncconnection.c Emit main context 12
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.621: ../../src/vncconnection.c Requested auth subtype 261
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.622: ../../src/vncconnection.c Waiting for VeNCrypt auth subtype
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.623: ../../src/vncconnection.c Choose auth 261
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.624: ../../src/vncconnection.c Checking if credentials are needed
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.625: ../../src/vncconnection.c No credentials required
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.674: ../../src/vncconnection.c Read error A non-blocking socket operation could not be completed immediately.
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.706: ../../src/vncconnection.c Do TLS handshake
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.740: ../../src/vncconnection.c Checking if credentials are needed
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.740: ../../src/vncconnection.c Want a TLS clientname
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.741: ../../src/vncconnection.c Requesting missing credentials
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.744: ../../src/vncconnection.c Emit main context 10
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.774: ../../src/vncconnection.c Set credential 2 libvirt
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.822: ../../src/vncconnection.c Searching for certs in /usr/x86_64-w64-mingw32/sys-root/mingw/etc/pki
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.838: ../../src/vncconnection.c Failed to find certificate CA/cacrl.pem
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.840: ../../src/vncconnection.c Failed to find certificate libvirt/private/clientkey.pem
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.884: ../../src/vncconnection.c Failed to find certificate libvirt/clientcert.pem
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.885: ../../src/vncconnection.c Waiting for missing credentials
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.886: ../../src/vncconnection.c Got all credentials
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890: ../../src/vncconnection.c No client cert or key provided
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890: ../../src/vncconnection.c No CA revocation list provided
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.892: ../../src/vncconnection.c Error: Failed to complete handshake Error in the pull function.
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.896: ../../src/vncconnection.c Emit main context 16

(remote-viewer.exe:23460): virt-viewer-WARNING **: 14:12:47.900: vnc-session: got vnc error Failed to complete handshake Error in the pull function.
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.948: ../../src/vncdisplay.c VNC server error
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.951: ../../src/vncconnection.c Auth failed
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.952: ../../src/vncconnection.c Doing final VNC cleanup
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.953: ../../src/vncconnection.c Close VncConnection=000000000595D940
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.954: ../../src/vncconnection.c Emit main context 15
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.955: ../../src/vncdisplay.c Disconnected from VNC server
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.957: ../../src/vncdisplay.c Grab sequence is now
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:49.578: ../../src/vncconnection.c Init VncConnection=0000000009DC4590
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:49.579: ../../src/vncdisplaykeymap.c Using Win32 virtual keycode mapping
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:49.580: ../../src/vncdisplay.c Grab sequence is now Control_L+Alt_L
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:49.581: ../../src/vncdisplay.c Display destroy, requesting that VNC connection close
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:49.583: ../../src/vncdisplay.c Releasing VNC widget
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:49.584: ../../src/vncconnection.c Finalize VncConnection=0000000009DC4590

The important bit of the log is this:

(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.706: ../../src/vncconnection.c Do TLS handshake
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.740: ../../src/vncconnection.c Checking if credentials are needed
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.740: ../../src/vncconnection.c Want a TLS clientname
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.741: ../../src/vncconnection.c Requesting missing credentials
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.744: ../../src/vncconnection.c Emit main context 10
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.774: ../../src/vncconnection.c Set credential 2 libvirt
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.822: ../../src/vncconnection.c Searching for certs in /usr/x86_64-w64-mingw32/sys-root/mingw/etc/pki
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.838: ../../src/vncconnection.c Failed to find certificate CA/cacrl.pem
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.840: ../../src/vncconnection.c Failed to find certificate libvirt/private/clientkey.pem
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.884: ../../src/vncconnection.c Failed to find certificate libvirt/clientcert.pem
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.885: ../../src/vncconnection.c Waiting for missing credentials
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.886: ../../src/vncconnection.c Got all credentials
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890: ../../src/vncconnection.c No client cert or key provided
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890: ../../src/vncconnection.c No CA revocation list provided
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.892: ../../src/vncconnection.c Error: Failed to complete handshake Error in the pull function.

From that I can infer it successfully found the CA certificate (bundle) you installed at "C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\CA\cacert.pem"

It did not find any client certificate/key, but carried on and attempted the TLS handshake without them.

The handshake got an error, which suggests that the VNC server mandates the use of the client certificates

IOW, I think you also need the files:

C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\libvirt\clientcert.pem
C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\libvirt\private\clientkey.pem

to be present to communicate with this server.

I'm not sure if that's expected with RHV ? If so, I'm not sure where you'd get a suitable client cert/key from

(In reply to Daniel Berrangé from comment #8)
> The important bit of the log is this:
> 
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.706:
> ../../src/vncconnection.c Do TLS handshake
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.740:
> ../../src/vncconnection.c Checking if credentials are needed
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.740:
> ../../src/vncconnection.c Want a TLS clientname
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.741:
> ../../src/vncconnection.c Requesting missing credentials
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.744:
> ../../src/vncconnection.c Emit main context 10
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.774:
> ../../src/vncconnection.c Set credential 2 libvirt
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.822:
> ../../src/vncconnection.c Searching for certs in
> /usr/x86_64-w64-mingw32/sys-root/mingw/etc/pki
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.838:
> ../../src/vncconnection.c Failed to find certificate CA/cacrl.pem
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.840:
> ../../src/vncconnection.c Failed to find certificate
> libvirt/private/clientkey.pem
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.884:
> ../../src/vncconnection.c Failed to find certificate libvirt/clientcert.pem
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.885:
> ../../src/vncconnection.c Waiting for missing credentials
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.886:
> ../../src/vncconnection.c Got all credentials
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890:
> ../../src/vncconnection.c No client cert or key provided
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890:
> ../../src/vncconnection.c No CA revocation list provided
> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.892:
> ../../src/vncconnection.c Error: Failed to complete handshake Error in the
> pull function.
> 
> From that I can infer it successfully found the CA certificate (bundle) you
> installed at "C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\CA\cacert.pem"
> 
> It did not find any client certificate/key, but carried on and attempted the
> TLS handshake without them.
> 
> The handshake got an error, which suggests that the VNC server mandates the
> use of the client certificates
> 
> IOW, I think you also need the files:
> 
> C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\libvirt\clientcert.pem
> C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki\libvirt\private\clientkey.
> pem
> 
> to be present to communicate with this server.
> 
> I'm not sure if that's expected with RHV ? If so, I'm not sure where you'd
> get a suitable client cert/key from

So the RHV VNC does not use client certificates, RHV uses vnc with a normal password, it's just transport encryption for VNC


the console.vv looks like this:

[virt-viewer]
type=vnc
host=hypervisor1.tld
port=5900
password=randomPassword
# Password is valid for 120 seconds.
delete-this-file=1
fullscreen=0
title=vmName:%d
toggle-fullscreen=shift+f11
release-cursor=shift+f12
secure-attention=ctrl+alt+end
versions=rhev-win64:2.0-160;rhev-win32:2.0-160;rhel8:7.0-3;rhel7:2.0-6;rhel6:99.0-1
newer-version-url=https://rhv-manager.tld/ovirt-engine/rhv/client-resources

[ovirt]
host=rhv-manager.tld:443
vm-guid=00000000-0000-0000-0000-000000000000
sso-token=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000
admin=1
ca=-----[CA File]...


I can also say it works fine with virt-viwer 11 as packaged in fedora 38 (at least on oVirt, don't have RHV at home :)

Main differences are here:
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.484: ../src/vncconnection.c Server version: 3.8
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.484: ../src/vncconnection.c Sending full greeting
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.484: ../src/vncconnection.c Using version: 3.8
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.494: ../src/vncconnection.c Possible auth 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Emit main context 14
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Thinking about auth type 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Decided on auth type 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Waiting for auth type
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Choose auth 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c No credentials required
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Do Challenge
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Want a password
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Requesting missing credentials
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Emit main context 13
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Set credential 0 PasswordHere
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Waiting for missing credentials
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Got all credentials
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.506: ../src/vncconnection.c Checking auth result
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.507: ../src/vncconnection.c Success
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.509: ../src/vncconnection.c Initial desktop size 1024x768 <p></p>

So if I am reading this right, windows virt viewer choses different auth methods, none of them seem to be password like supplied in the console.vv file.

> So the RHV VNC does not use client certificates, RHV uses vnc with a normal password, it's just transport encryption for VNC

Ok, but the log definitely suggests that he QEMU VNC server has terminated the connection, which does rather suggest it wants client side certs.

The QEMU command line for the VM in question would help us understand the server side config if uou have that available.


> (remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Choose auth 2

> So if I am reading this right, windows virt viewer choses different auth methods, none of them seem to be password like supplied in the console.vv file.

Yes, here it has chosen plain old boring password based authentication


where as your RHV log:

> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.444: ../../src/vncconnection.c Choose auth 19

This is VeNCrypt auth

> (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.623: ../../src/vncconnection.c Choose auth 261

And this is TLS with x509, combined with password authentication

The log shows we start the TLS handshake, but didn't complete, so didn't get as far as trying the password bit.

(In reply to Daniel Berrangé from comment #10)
> > So the RHV VNC does not use client certificates, RHV uses vnc with a normal password, it's just transport encryption for VNC
> 
> Ok, but the log definitely suggests that he QEMU VNC server has terminated
> the connection, which does rather suggest it wants client side certs.
> 
> The QEMU command line for the VM in question would help us understand the
> server side config if uou have that available.

Yeah, should be no problem, but I'm no longer in office, will get that tomorrow

> 
> 
> > (remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Choose auth 2
> 
> > So if I am reading this right, windows virt viewer choses different auth methods, none of them seem to be password like supplied in the console.vv file.
> 
> Yes, here it has chosen plain old boring password based authentication
> 
> 
> where as your RHV log:
> 
> > (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.444: ../../src/vncconnection.c Choose auth 19
> 
> This is VeNCrypt auth
> 
> > (remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.623: ../../src/vncconnection.c Choose auth 261
> 
> And this is TLS with x509, combined with password authentication
> 
> The log shows we start the TLS handshake, but didn't complete, so didn't get
> as far as trying the password bit.

This is the full log from my homelab (current ovirt with client virt-viewer-11.0-6.fc38.x86_64 on fedora 38)

$ remote-viewer -vvv --gtk-vnc-debug console.vv
Guest (null) has a vnc display
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.458: ../src/vncconnection.c Init VncConnection=0x559a48c8e6f0
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.458: ../src/vncdisplaykeymap.c Using Wayland evdev virtual keycode mapping
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.458: ../src/vncdisplay.c Grab sequence is now Control_L+Alt_L
Opening connection to display at console.vv
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.463: ../src/vncconnection.c Open host=hypervisor.tld port=5919
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.477: ../src/vncconnection.c Open coroutine starting
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.477: ../src/vncconnection.c Started background coroutine
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.477: ../src/vncconnection.c Resolving host hypervisor.tld 5919
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.478: ../src/vncconnection.c Trying one socket
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.478: ../src/vncconnection.c Schedule socket timeout 0x559a48c8d418
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.478: ../src/vncconnection.c Socket pending
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.482: ../src/vncconnection.c Finally connected
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.482: ../src/vncconnection.c Remove timeout 0x559a48c8d418
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.482: ../src/vncconnection.c Emit main context 16
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.482: ../src/vncdisplay.c Grab sequence is now 
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.483: ../src/vncdisplay.c Connected to VNC server
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.483: ../src/vncconnection.c Protocol initialization
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.483: ../src/vncconnection.c Schedule greeting timeout 0x559a48c8d418
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.484: ../src/vncconnection.c Remove timeout 0x559a48c8d418
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.484: ../src/vncconnection.c Server version: 3.8
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.484: ../src/vncconnection.c Sending full greeting
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.484: ../src/vncconnection.c Using version: 3.8
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.494: ../src/vncconnection.c Possible auth 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Emit main context 14
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Thinking about auth type 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Decided on auth type 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Waiting for auth type
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Choose auth 2
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c No credentials required
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Do Challenge
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Want a password
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Requesting missing credentials
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Emit main context 13
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Set credential 0 PasswordHere
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Waiting for missing credentials
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.504: ../src/vncconnection.c Got all credentials
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.506: ../src/vncconnection.c Checking auth result
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.507: ../src/vncconnection.c Success
(remote-viewer:18205): gtk-vnc-DEBUG: 15:23:19.509: ../src/vncconnection.c Initial desktop size 1024x768

The first auth it tries here is 2 -- VNC_CONNECTION_AUTH_VNC https://gitlab.gnome.org/GNOME/gtk-vnc/-/blob/master/src/vncconnection.h#L152-166

on windows VirtViewer v9.0-96 the first auth it tries is 19 -- VNC_CONNECTION_AUTH_VENCRYPT after that 261 VNC_CONNECTION_AUTH_VENCRYPT_X509VNC -- so does it misidentify VNC as VENCRYPT on windows?

this happens here:
https://gitlab.gnome.org/GNOME/gtk-vnc/-/blob/master/src/vncconnection.c#L5089-5122
but I fail to understand where it could go wrong

QEMU cli from /var/log/libvirt/qemu/HostedEngine.log


I am guessing the relevant lines are this:
-object '{"qom-type":"tls-creds-x509","id":"vnc-tls-creds0","dir":"/etc/pki/vdsm/libvirt-vnc","endpoint":"server","verify-peer":false}' \
-vnc 10.33.16.51:0,password=on,tls-creds=vnc-tls-creds0,audiodev=audio1 \

Full cli:
/usr/libexec/qemu-kvm \
-name guest=HostedEngine,debug-threads=on \
-S \
-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-3-HostedEngine/master-key.aes"}' \
-machine pc-q35-rhel8.6.0,usb=off,dump-guest-core=off,graphics=off \
-accel kvm \
-cpu Icelake-Server-noTSX,mpx=off,intel-pt=off \
-m size=52428800k,slots=16,maxmem=209715200k \
-overcommit mem-lock=off \
-smp 12,maxcpus=120,sockets=10,dies=1,cores=12,threads=1 \
-object '{"qom-type":"iothread","id":"iothread1"}' \
-object '{"qom-type":"memory-backend-ram","id":"ram-node0","size":53687091200}' \
-numa node,nodeid=0,cpus=0-119,memdev=ram-node0 \
-uuid 28de9297-a63f-4070-98e5-7be4869bd506 \
-smbios 'type=1,manufacturer=Red Hat,product=RHEL,version=8.6-6.el8ev,serial=4c4c4544-0033-5210-8031-b4c04f345333,uuid=28de9297-a63f-4070-98e5-7be4869bd506,sku=8.6.0,family=RHV' \
-smbios 'type=2,manufacturer=Red Hat,product=RHEL-AV' \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=39,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=2023-04-14T09:34:29,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device pcie-root-port,port=16,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
-device pcie-root-port,port=17,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=18,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=19,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=20,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=21,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=22,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=23,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
-device pcie-root-port,port=24,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 \
-device pcie-root-port,port=25,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 \
-device pcie-root-port,port=26,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x2 \
-device pcie-root-port,port=27,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x3 \
-device pcie-root-port,port=28,chassis=13,id=pci.13,bus=pcie.0,addr=0x3.0x4 \
-device pcie-root-port,port=29,chassis=14,id=pci.14,bus=pcie.0,addr=0x3.0x5 \
-device pcie-root-port,port=30,chassis=15,id=pci.15,bus=pcie.0,addr=0x3.0x6 \
-device pcie-root-port,port=31,chassis=16,id=pci.16,bus=pcie.0,addr=0x3.0x7 \
-device pcie-root-port,port=32,chassis=17,id=pci.17,bus=pcie.0,addr=0x4 \
-device pcie-pci-bridge,id=pci.18,bus=pci.1,addr=0x0 \
-device qemu-xhci,p2=8,p3=8,id=ua-216ba05f-d246-4b6f-909b-abee17553f9d,bus=pci.3,addr=0x0 \
-device virtio-scsi-pci,iothread=iothread1,id=ua-f1cdefcd-5ff3-44ef-bc8a-bd62b96a5f02,bus=pci.5,addr=0x0 \
-device virtio-serial-pci,id=ua-2770a393-6786-4a11-850c-33f7ab133a75,max_ports=16,bus=pci.4,addr=0x0 \
-device ide-cd,bus=ide.2,id=ua-8032d60f-12db-4055-bca4-7360ad63c965,werror=report,rerror=report \
-blockdev '{"driver":"file","filename":"/run/vdsm/storage/d3bc23a9-d07f-4a45-91ce-bd6c0fb9859f/1f1151e8-a819-47b5-93b8-aa2458ac2ad4/a430f917-117c-4da7-8091-ee30528b9a96","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \
-device virtio-blk-pci,iothread=iothread1,bus=pci.6,addr=0x0,drive=libvirt-1-format,id=ua-1f1151e8-a819-47b5-93b8-aa2458ac2ad4,bootindex=1,write-cache=on,serial=1f1151e8-a819-47b5-93b8-aa2458ac2ad4,werror=stop,rerror=stop \
-netdev tap,fds=40:42:43:44,id=hostua-1c39b426-9248-4650-b367-fddd2373aa4f,vhost=on,vhostfds=45:46:47:48 \
-device virtio-net-pci,mq=on,vectors=10,host_mtu=1500,netdev=hostua-1c39b426-9248-4650-b367-fddd2373aa4f,id=ua-1c39b426-9248-4650-b367-fddd2373aa4f,mac=00:16:3e:1f:95:d1,bus=pci.2,addr=0x0 \
-chardev socket,id=charserial0,fd=36,server=on,wait=off \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=37,server=on,wait=off \
-device virtserialport,bus=ua-2770a393-6786-4a11-850c-33f7ab133a75.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-chardev socket,id=charchannel1,fd=38,server=on,wait=off \
-device virtserialport,bus=ua-2770a393-6786-4a11-850c-33f7ab133a75.0,nr=2,chardev=charchannel1,id=channel1,name=org.ovirt.hosted-engine-setup.0 \
-device usb-tablet,id=input0,bus=ua-216ba05f-d246-4b6f-909b-abee17553f9d.0,port=1 \
-audiodev '{"id":"audio1","driver":"none"}' \
-object '{"qom-type":"tls-creds-x509","id":"vnc-tls-creds0","dir":"/etc/pki/vdsm/libvirt-vnc","endpoint":"server","verify-peer":false}' \
-vnc 10.33.16.51:0,password=on,tls-creds=vnc-tls-creds0,audiodev=audio1 \
-k en-us \
-device qxl-vga,id=ua-54f27992-a988-4ab9-94d2-be90023d1cdf,ram_size=67108864,vram_size=33554432,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \
-device intel-hda,id=ua-da7aef03-9fd5-4d2b-9805-24f1302d0aa1,bus=pci.18,addr=0x1 \
-device hda-duplex,id=ua-da7aef03-9fd5-4d2b-9805-24f1302d0aa1-codec0,bus=ua-da7aef03-9fd5-4d2b-9805-24f1302d0aa1.0,cad=0,audiodev=audio1 \
-device virtio-balloon-pci,id=ua-23c885db-4826-4dcc-bbfd-88e54aadf72e,bus=pci.7,addr=0x0 \
-object '{"qom-type":"rng-random","id":"objua-6b4de2d0-aa44-4075-9df6-da427bba789d","filename":"/dev/urandom"}' \
-device virtio-rng-pci,rng=objua-6b4de2d0-aa44-4075-9df6-da427bba789d,id=ua-6b4de2d0-aa44-4075-9df6-da427bba789d,bus=pci.8,addr=0x0 \
-device vmcoreinfo \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on


# ls -al /etc/pki/vdsm/libvirt-vnc
total 16
drwxr-xr-x. 2 vdsm kvm   70 Apr 13 07:44 .
drwxr-xr-x. 8 vdsm kvm  105 Apr 14 08:01 ..
-rw-r--r--. 1 root kvm 1392 Mar 23 09:52 ca-cert.pem
-rw-r--r--. 1 root kvm 5297 Apr 13 07:43 server-cert.pem
-r--r-----. 1 vdsm kvm 1704 Apr 13 07:42 server-key.pem

/etc/pki/vdsm/libvirt-vnc/ca-cert.pem is the engine ca
/etc/pki/vdsm/libvirt-vnc/server-cert.pem is the certificate for the hypervisor signed by engine ca

The ovirt machines I have in my homelab do not have

"-object '{"qom-type":"tls-creds-x509","id":"vnc-tls-creds0","dir":"/etc/pki/vdsm/libvirt-vnc","endpoint":"server","verify-peer":false}'"

But both clusters have VNC encryption enabled in the cluster configuration. So I am guessing ovirt-vnc homelab simply has no encryption even though it should have, guess that's another error then, so the question for this bug and the RHV side remains the same as before, should it do a password auth after trying and failing at client certs?

So it seems the issue in my homelab is confined to one of the clusters, even though both clusters have vnc encryption enabled, only one of them actually encrypts vnc :)

I pulled a log with gtk-vnc-debug that successfully connects to an encrypted ovirt VM via fedora 38 remote-viewer:


Differences windows/linux:

Windows:
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.886: ../../src/vncconnection.c Got all credentials
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890: ../../src/vncconnection.c No client cert or key provided
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.890: ../../src/vncconnection.c No CA revocation list provided
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.892: ../../src/vncconnection.c Error: Failed to complete handshake Error in the pull function.
(remote-viewer.exe:23460): gtk-vnc-DEBUG: 14:12:47.896: ../../src/vncconnection.c Emit main context 16

Linux:
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Got all credentials
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c No CA certificate provided; trying the system trust store instead
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.408: ../src/vncconnection.c Using the system trust store and CRL
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.408: ../src/vncconnection.c No client cert or key provided
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.408: ../src/vncconnection.c No CA revocation list provided
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.409: ../src/vncconnection.c Handshake was blocking
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.416: ../src/vncconnection.c Handshake done




Full log:
$ remote-viewer --gtk-vnc-debug -vvv console.vv
Guest (null) has a vnc display
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.286: ../src/vncconnection.c Init VncConnection=0x55864e472030
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.286: ../src/vncdisplaykeymap.c Using Wayland evdev virtual keycode mapping
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.286: ../src/vncdisplay.c Grab sequence is now Control_L+Alt_L Opening connection to display at console.vv
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.291: ../src/vncconnection.c Open host=192.168.0.33 port=5900
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.306: ../src/vncconnection.c Open coroutine starting
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.306: ../src/vncconnection.c Started background coroutine
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.306: ../src/vncconnection.c Resolving host 192.168.0.33 5900
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.306: ../src/vncconnection.c Trying one socket
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.306: ../src/vncconnection.c Schedule socket timeout 0x55864e470d58
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.306: ../src/vncconnection.c Socket pending
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.308: ../src/vncconnection.c Finally connected
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.308: ../src/vncconnection.c Remove timeout 0x55864e470d58
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.310: ../src/vncconnection.c Emit main context 16
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.310: ../src/vncdisplay.c Grab sequence is now
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.311: ../src/vncdisplay.c Connected to VNC server
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.311: ../src/vncconnection.c Protocol initialization
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.311: ../src/vncconnection.c Schedule greeting timeout 0x55864e470d58
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.312: ../src/vncconnection.c Remove timeout 0x55864e470d58
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.312: ../src/vncconnection.c Server version: 3.8
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.312: ../src/vncconnection.c Sending full greeting
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.312: ../src/vncconnection.c Using version: 3.8
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.343: ../src/vncconnection.c Possible auth 19
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.353: ../src/vncconnection.c Emit main context 14
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.353: ../src/vncconnection.c Thinking about auth type 19
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.353: ../src/vncconnection.c Decided on auth type 19
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.353: ../src/vncconnection.c Waiting for auth type
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.353: ../src/vncconnection.c Choose auth 19
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.353: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.353: ../src/vncconnection.c No credentials required
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.357: ../src/vncconnection.c Possible VeNCrypt sub-auth 261
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.357: ../src/vncconnection.c Emit main context 15
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.357: ../src/vncconnection.c Requested auth subtype 261
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.357: ../src/vncconnection.c Waiting for VeNCrypt auth subtype
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.357: ../src/vncconnection.c Choose auth subtype 261
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.357: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.357: ../src/vncconnection.c No credentials required
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Do TLS handshake
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Want a TLS clientname
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Requesting missing credentials
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Emit main context 13
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Set credential 2 libvirt
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Searching for certs in /etc/pki
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Searching for certs in /home/klaas/.pki
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Failed to find certificate CA/cacert.pem
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c No CA certificate provided, using GNUTLS global trust
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Failed to find certificate CA/cacrl.pem
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Failed to find certificate libvirt/private/clientkey.pem
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Failed to find certificate libvirt/clientcert.pem
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Waiting for missing credentials
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c Got all credentials
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.359: ../src/vncconnection.c No CA certificate provided; trying the system trust store instead
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.408: ../src/vncconnection.c Using the system trust store and CRL
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.408: ../src/vncconnection.c No client cert or key provided
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.408: ../src/vncconnection.c No CA revocation list provided
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.409: ../src/vncconnection.c Handshake was blocking
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.416: ../src/vncconnection.c Handshake done
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.416: ../src/vncconnection.c Validating
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Certificate is valid.
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Checking chain 0
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Completed TLS setup, do subauth 261
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Handing off to VNC auth
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Do Challenge
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Checking if credentials are needed
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Want a password
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Requesting missing credentials
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Emit main context 13
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Set credential 0 Passwordhere
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Waiting for missing credentials
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.418: ../src/vncconnection.c Got all credentials
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.469: ../src/vncconnection.c Checking auth result
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.471: ../src/vncconnection.c Success
(remote-viewer:46393): gtk-vnc-DEBUG: 10:40:44.473: ../src/vncconnection.c Initial desktop size 720x400

So I guess were here: https://gitlab.gnome.org/GNOME/gtk-vnc/-/blame/master/src/vncconnection.c?no_pagination=true#L4800-4812 and this is a gnutls error specific to windows or the version thats being used in the rhv virt-viewer?

(In reply to Klaas Demter from comment #15)
> So I guess were here:
> https://gitlab.gnome.org/GNOME/gtk-vnc/-/blame/master/src/vncconnection.
> c?no_pagination=true#L4800-4812 and this is a gnutls error specific to
> windows or the version thats being used in the rhv virt-viewer?

When it talks about the "pull function" i"m assuming it means it is seeing an error back from

https://gitlab.gnome.org/GNOME/gtk-vnc/-/blame/master/src/vncconnection.c?no_pagination=true#L1130-1155

though i would have expected the log to show evidence of:

  VNC_DEBUG("Read error %s", error->message)

unless g_socket_receive returned -1, without setting 'error' which would be rather bad.

It seems to fail the same way with the upstream virt-viewer-x64-11.0-1.0.msi, based on Fedora 34.

https://gitlab.gnome.org/GNOME/gtk-vnc/-/merge_requests/24
https://gitlab.com/virt-viewer/virt-viewer/-/merge_requests/140

This should fix it on Windows also :)

(In reply to Jean-Louis Dupond from comment #18)
> https://gitlab.gnome.org/GNOME/gtk-vnc/-/merge_requests/24
> https://gitlab.com/virt-viewer/virt-viewer/-/merge_requests/140
> 
> This should fix it on Windows also :)

While this fixes the reason this case started, I don't think it will fix what Daniel said in https://bugzilla.redhat.com/show_bug.cgi?id=2186439#c16

I've modified the title to be more fitting to the most recent discoveries :)

so does it break differently now? there's probably no reason to track this against RHV anymore as backporting all of these are unlikely

(In reply to Michal Skrivanek from comment #21)
> so does it break differently now? there's probably no reason to track this
> against RHV anymore as backporting all of these are unlikely

Hi Michal,
no it always broke in the same way 'Error: Failed to complete handshake Error in the pull function.' we just initially thought it is because of a missing/misplaced CA cert.

What product should I change this to? Or should this be filed in the virt-viewer gitlab?

Greetings
Klaas

(In reply to Klaas Demter from comment #22)
> (In reply to Michal Skrivanek from comment #21)
> > so does it break differently now? there's probably no reason to track this
> > against RHV anymore as backporting all of these are unlikely
> 
> Hi Michal,
> no it always broke in the same way 'Error: Failed to complete handshake
> Error in the pull function.' we just initially thought it is because of a
> missing/misplaced CA cert.
> 
> What product should I change this to? Or should this be filed in the
> virt-viewer gitlab?
> 
> Greetings
> Klaas

Hi Klaas, yeah, either that or move this to latest RHEL. This bugzilla only tracks RHV product, and that is in Maintenance phase, low severity issues are not being backported. Technically this is virt-viewer that belongs to RHEL, not RHV, so it could be tracked for RHEL product instead(despite the binary being for Windows in the end:-) But since the supported RHEL to "go along" with RHV is 8.6 it's pretty much the same situation, a backport is unlikely.
It may be valid to claim it doesn't work in RHEL 9 (as opposed to "the current version supplied with RHV 4.4 SP1")
You shouldn't need to decide yourself, since you raised a RHV support ticket they should help you to find the best rpath forward.

Thanks,
michal

Okay, moving it to rhel9 virt-viewer

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.