From https://bugzilla.redhat.com/show_bug.cgi?id=1305785 Description of problem: spice-gtk (and thus remote-viewer) use OpenSSL to verify the SSL certificate used to encrypt the spice connection. It is possible to provide a trusted CA file or trusted CA certificate(s) in the remote-viewer configuration file (options "ca-file" and "ca"). Unfortunately, spice-gtk will only accept root certificates as trusted, it is therefor not possible to provide only the server or intermediate certificate when connecting. Accepting provided intermediate (or server) certificates would actually provide better security because of the more limited scope, as well as ease deployment in a non-self-signed setup: the usual work flow is to configure the chain up to but excluding the root certificate on the server side, if the server is also responsible for generating the configuration files, it needs to acquire and provide the correct root certificate via a separate mechanism. Steps to Reproduce: 1. run a spice server instance configured with an intermediate and end certificate, but not the root 2. create a remote-viewer configuration file with ca="<PEM encoded version of intermediate>" 3. try to connect using remote-viewer Actual results: Connection fails, with the following error message: (/usr/bin/remote-viewer:2416): Spice-Warning **: ssl_verify.c:429:openssl_verify: Error in certificate chain verification: unable to get local issuer certificate (num=20:depth1:/CN=XXX CA) (remote-viewer:2416): GSpice-WARNING **: main-1:0: SSL_connect: error:00000001:lib(0):func(0):reason(1) Expected results: remote-viewer / spice-gtk should accept the provided CA certificate as trusted, even if it is not a root certificate. The connection should not fail ;) Additional info: See https://lists.freedesktop.org/archives/spice-devel/2016-February/026214.html for a more in-depth description.
I think we have 2 options here, 1) either just accept the intermediate CA as valid and do not fail if the only issue is that its "end" CA cert is invalid 2) or when the "end" CA cert is invalid, look up in the system truststore and see if this makes the whole chain valid. In order to match existing behaviour when the passed-in CA goes down to the root chain, we have to validate the certificate presented by the server using only the intermediate CA, and if all goes well, finish the validation using the system truststore. 1) is probably easier, and more consistent with what is currently done. I suspect 2) is slightly more correct, but could be wrong.
Original reporter here. For our use case, either 1 or 2 is probably fine, but I would prefer version 1 because there are no (potentially failing) dependencies on the user's or OS trust store. Version 2 seems to be stricter, but IMHO only limits the possible valid configurations without any security benefit. If an attacker is able to modify the configuration file and changes the ca parameter (e.g., for MITM purposes), they can currently already include their root certificate and pass all checks. If the attacker cannot change the configuration file, I see no reason to require an explicit pinning of the root in addition to the intermediate certificate. OTOH, I might have missed a different setup where this distinction is relevant. Requiring a trusted root certificate if there is no ca(-file) parameter seems reasonable.
Please go for option 1. I have been waiting for getting spice working on proxmox again since 2016.
(In reply to Asger Stig Holten from comment #3) > Please go for option 1. I have been waiting for getting spice working on > proxmox again since 2016. we worked around this Spice issue by splitting the certificates used for the web interface and those used for Spice. if Spice is not working for you on PVE, please open a thread on the PVE support forum.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/spice/spice-gtk/issues/30.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.