Hello, I noticed a rather strange (IMHO) behavior of spice-gtk regarding SSL certificate verification, and am wondering whether this is intentional. My current test setups looks like this: root cert -> intermediate cert -> node cert I use three SSL related files for setting up the server side of Spice: ssl-key.pem (private key) ssl-cert.pem (node cert + intermediate cert, this is used for HTTPS purposes as well) ca.pem (A: intermediate cert, B: intermediate + root cert) Variants A and B produce the same results. If I only put the PEM-encoded intermediate certificate into the remote-viewer configuration file, the connection will fail: (/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) If I put the intermediate and the root certificate into the remote-viewer configuration file, everything works as expected (even though the ~/.spicec/spice_truststore.pem file does not exist and the root certificate used in this example is not trusted by the operating system's trust store). Why does the Spice client only accept a certificate if the root certificate is available? Shouldn't pinning on an intermediate level (i.e., the certificate provided in the "ca" parameter of the remote-viewer configuration file) work equally well? Especially since both the intermediate and the root are not contained in any trust store and are thus equally (un)trusted, this behavior is quite unexpected.. Some background: this came up while evaluating Let's Encrypt (but the same is probably true for other, commercial CAs) which only provides the chain up to, but excluding the, root certificate. This makes sense, since the root certificate is usually provided independently by the client/OS/.. trust store. While it is possible to work around this by parsing the intermediate and downloading the root certificate, this seems quite cumbersome and inefficient, with no real benefits. In our case, this would mean obtaining and storing an extra root certificate for each node just to keep Spice happy (with no security benefits at all), or burdening the end users with keeping a Spice trust store file complete and current themselves.. Maybe I missed a configuration option somewhere that would enable the expected behavior? Passing --spice-ca-file to remote-viewer seems to override/extend what is contained in the remote-viewer configuration file, but also only works for the root certificate, and not the intermediate. I tried all of the above with remote-viewer included in Debian Jessie (1.0-1) as well as compiled from current source, with no difference whatsoever. Regards, Fabian _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel